Assign values to attributes

Rails
1

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.

2

On 7 January 2011 22:45, Villm [email protected] wrote:

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

I do that but it seems doesn’t work.

3

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
@suplier.save
…

Or maybe, if you want rescue errors:

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
…

Regards,

Giorgio

4

Have you tried adding the last line?

def create
@supplier = Supplier.new(params[:supplier])
@supplier.durc_expiry_date = @supplier.durc_issue_date + 90.days

@suplier.save <-------------------THIS ONE

…

5

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.

6

On 7 January 2011 21:18, Mauro [email protected] wrote:

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.

Colin

7

On 7 January 2011 23:25, Villm [email protected] wrote:

Have you tried adding the last line?

def create
@supplier = Supplier.new(params[:supplier])
@supplier.durc_expiry_date = @supplier.durc_issue_date + 90.days

@suplier.save <-------------------THIS ONE

this is the entire code:

def create
@supplier = Supplier.new(params[:supplier])
@supplier.durc_expiry_date = @supplier.durc_issue_date + 90.days

respond_to do |format|
  if @supplier.save
    format.html { redirect_to(@supplier, :notice => t('Supplier

was successfully created.')) }
format.xml { render :xml => @supplier, :status => :created,
:location => @supplier }
else
format.html { render :action => “new” }
format.xml { render :xml => @supplier.errors, :status =>
:unprocessable_entity }
end
end
end

8

On 8 January 2011 10:13, Mauro [email protected] wrote:

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.

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.

Colin

9

On 8 January 2011 11:23, Colin L. [email protected] wrote:

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?

10

On 8 January 2011 09:19, Colin L. [email protected] wrote:

Is there an expiry_date column in the database?

Yes there is.

can ever be nil.
I have not thought about this, I have put curc_expiry_date in the
database, is it wrong?

11

On 8 January 2011 10:43, Mauro [email protected] wrote:

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.

Colin

12

On 8 January 2011 12:11, Colin L. [email protected] wrote:

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

13

On 8 January 2011 11:54, Mauro [email protected] wrote:

issue_date + 90.days
end

without the word self.
Is it the same thing?

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.

Colin

14

On 8 January 2011 13:20, Colin L. [email protected] wrote:

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.

I’ve changed the default date to null.
Thank you for your tips.