In my model I did self.durc_expiry_date = self.durc_issue_date +
90.days but I think it is not a best practice to update attributes
from model.
So I remove that code and put
def create @supplier = Supplier.new(params[:supplier]) @supplier.durc_expiry_date = @supplier.durc_issue_date + 90.days
…
in the controller.
But doing so I have no values in durc.expiry.date.
IMHO, your first attempt, update attributes in model, is the best
practice because model is where you keep attention of your data.
Anyway, to save your data in the controller:
IMHO, your first attempt, update attributes in model, is the best
practice because model is where you keep attention of your data.
Anyway, to save your data in the controller:
def create @supplier = Supplier.new(params[:supplier]) @supplier.durc_expiry_date = @supplier.durc_issue_date + 90.days
if @suplier.save
do stuff
else
do other stuff
end
…
I think it is not a best practice to update attributes from model.
In MVC architectures business logic typically resides within models,
so setting your expiration date business rule within the Supplier
model would be the recommended practice.
But doing so I have no values in durc.expiry.date.
Is there an expiry_date column in the database? You can only put it
in the controller if that column exists. However, if the expiry date
is always +90 days then you should not put it in the database, but
should provide an instance method in the model, something like
def expiry_date
self.issue_date + 90.days
end
Then you can say durc.expiry_date and will always get issue date + 90
days. The method may have to be a little more complex if issue_date
can ever be nil.
Then you can say durc.expiry_date and will always get issue date + 90
days. The method may have to be a little more complex if issue_date
can ever be nil.
I have not thought about this, I have put curc_expiry_date in the
database, is it wrong?
If expiry date can always be calculated from issue date then it is
wrong to put expiry date in the database. It increases the database
size and access time but also adds complexity to the code. For
example you have to remember to update it whenever the issue date is
changed. If you use a method to access it the code is simpler. Note
that other code accessing curc.expiry_date will not see any difference
between a value stored in the database and the access method I have
suggested. This is known as a virtual attribute. You might like to
google for database normalization if you want to find more about how
to design the database.
If expiry date can always be calculated from issue date then it is
wrong to put expiry date in the database. It increases the database
size and access time but also adds complexity to the code. For
example you have to remember to update it whenever the issue date is
changed. If you use a method to access it the code is simpler. Note
that other code accessing curc.expiry_date will not see any difference
between a value stored in the database and the access method I have
suggested. This is known as a virtual attribute. You might like to
google for database normalization if you want to find more about how
to design the database.
Thank you for very useful information.
I should put protected the instance method in the model?
suggested. This is known as a virtual attribute. You might like to
google for database normalization if you want to find more about how
to design the database.
Thank you for very useful information.
I should put protected the instance method in the model?
If you do that then it will not be able to be used in controller or views.
Yes you are right sorry for my ignorance.
in the instance method
def expiry_date
self.issue_date + 90.days
end
I can do
def expiry_date
issue_date + 90.days
end
without the word self.
Is it the same thing?
Specifically I’ve done in my model:
def default_date
Date.new(1970, 01, 01)
end
def durc_expiry_date
unless durc_issue_date.eql?(default_date)
durc_issue_date + 90.days
else
default_date
end
end
Including the self keyword just ensures that it uses issue_date from
the current object. It jensures that the correct variable is used in
case there was another variable of the same name in scope. Some like
to do this as a matter of principle. I would always use self when assigning to an instance variable as otherwise a slight misspelling
will silently write to a local variable rather than the instance
variable.
else
default_date
end
end
I would generally use null in the database as the default date rather
than a specific value, but that is possibly a matter of taste.