I’d like some advice if poss.
I’ve got my app up and running and I’m very pleased. I’ve learned an
awful lot and learn more each day, ror is amazing.
I’ve got just two models in my DB at the moment - owners and properties,
an owner has many properties and a property belongs to an owner. I store
lots of things in the owner table including login information, notes as
well as the obvious stuff like name and address. A property is inactive
when first added by an owner (as it is not paid for) and later the admin
activates the property (just a boolean field that the admin can set but
not the owner). Everything works just fine and I’m very comfortable with
the existing setup (two tables built with migrations is a good way for
me to cut my teeth). As stated below I’d like to stay with two tables
for the time being (although I could be persuaded to introduce a new
model).
I’ve got a challenge now though that I’m not 100% sure how to handle. I
need to start recording when an owner pays. They pay per property for
one year up front. After payment the admin makes the property active.
My initial reaction is this, two new fields in the Property table -
datepaid(date) amountpaid(integer), I can then calculate a renewal date
by datepaid + oneyear. I don’t mind if later on I’ll be introducing a
payments history table but for now I just want a simple solution to get
me going?
I’d really appreciate any feedback.
bb
since it’s a per year payment you’ll definiteliy need an extra table to
handle multiple payments per property. no sense in making a ‘simple’
solution if it can’t even last one year.
and it’s easy enough, just a table payments which :belongs_to property
(needs a field property_id) and finished with it for the next years. and
amountpaid should be float if you’re not 100% sure never to get values
like 50.55
OK thanks - this is really helpful so I start to do things right. Float
is definately better (I set this up somewhere else also so I’ll change
it to float there also).
I drafted the following migration, does this look about right? I always
wonder if I should be doing something in here with defaults and
allow/disallow nulls?
Would you start with what’s below?, clearly I will set my belongs_to and
has_many in my models.
def self.up
create_table :payments do |table|
table.column :created_at, :date
table.column :updated_at, :date
table.column :date, :date
table.column :amount, :float
table.column :note, :text
table.column :property_id, :integer
end
end
def self.down
drop_table :payments
end
bingo bob wrote:
OK thanks - this is really helpful so I start to do things right. Float
is definately better (I set this up somewhere else also so I’ll change
it to float there also).
I drafted the following migration, does this look about right? I always
wonder if I should be doing something in here with defaults and
allow/disallow nulls?
Would you start with what’s below?, clearly I will set my belongs_to and
has_many in my models.
def self.up
create_table :payments do |table|
table.column :created_at, :date
table.column :updated_at, :date
table.column :date, :date
table.column :amount, :float
table.column :note, :text
table.column :property_id, :integer
end
end
def self.down
drop_table :payments
end
going on from this idea is the implementation. Payments is an admin
function and is closely linked to when a property becomes active (ie
normally a payment will be received and the property will become
active). Although a property could be paid for but then deactivated for
some reason (unlikely).
Renewal dates are another concept that needs to be considered.
Am thinking of a concept where there is perhaps a boolean field in the
property table (paid_up) that is automatically set as on if there is a
payment and the payment is not more than a year old.
or it could just be a manual thing, the admin sets the active field
manually (having knowledge of payments received)…any tips (hopefully
you can follow my train of thought)?
that looks fine so far
Am thinking of a concept where there is perhaps a boolean field in the
property table (paid_up) that is automatically set as on if there is a
payment and the payment is not more than a year old.
i would in this case use a date field like paid_until or valid_until,
which is set in the payment model whenever a new record is added, so you
can just add another year of being valid in the after_create.
just add one year to the old value. this would avoid trouble, if people
pay three months to early for the next year, eg the thing is valid until
08/12/31 and somebody decides in october to pay for next year, you add
one year and end up 09/12/31 instead of 09/10/30 or so. but a flag would
work too, depends on a lot of details in this case
or it could just be a manual thing, the admin sets the active field
manually (having knowledge of payments received)…any tips (hopefully
you can follow my train of thought)?
would be a lot of work. depending of the way you receive payment and how
many customers have to be expected. if payment is automatic (eg
creditcard or paypal), it would be way more comfortable to have
everything work automatic (and avoid trouble with wrong input by users)
i thought this paid_until_date to be in the property table not in
payments
so you can have several payments per property and the last one updates
the property/paid_until_date
OK thanks, I think I’ve got you, I think it’s like this…
migration…
def self.up
create_table :payments do |table|
table.column :created_at, :date
table.column :updated_at, :date
table.column :payment_date, :date
table.column :paid_until_date, :date
table.column :amount, :float
table.column :note, :text
table.column :property_id, :integer
end
end
def self.down
drop_table :payments
end
model…
and then make some changes in in my model (amazingly I’ve not been using
this after_create method thus far, haven’t seemed to need it) when a new
record is created the after_create method sets paid_until_date to be one
year from now OR if paid_until_date is not null it should set it to
paid_until_date + 1 year. phew, did i get it right?
bb
Thorsten M. wrote:
i thought this paid_until_date to be in the property table not in
payments
so you can have several payments per property and the last one updates
the property/paid_until_date
Yes - sorry my mistake…
I’ll add paid_until_date to the property table…not payments…
Thanks for this i’m on the right track,
One last thing, can you help with the syntax for my after_create method
- it goes in my payments model i assume, and does after_create
(property/paid_until_date by one year)?
I’ll implement this tonight after work :->
Thorsten M. wrote:
One last thing, can you help with the syntax for my after_create method
- it goes in my payments model i assume, and does after_create
(property/paid_until_date by one year)?
I’ll implement this tonight after work :->
this would be like that (yes, in payment model)
after_create :update_paid_until
def update_paid_until
check if paid_until_date is nil, then today + one year
otherwise paid_until_date + one year
end
xclnt,
I will try and implement, many thanks for your help today - this is I am
sure a far smarter way to do it and much more solid for the future :-).
One last thing, can you help with the syntax for my after_create method
- it goes in my payments model i assume, and does after_create
(property/paid_until_date by one year)?
I’ll implement this tonight after work :->
this would be like that (yes, in payment model)
after_create :update_paid_until
def update_paid_until
check if paid_until_date is nil, then today + one year
otherwise paid_until_date + one year
end
bingo bob wrote:
an owner has many properties and a property belongs to an owner. I store
lots of things in the owner table including login information, notes as
Will owners ALWAYS be the only users logging in? It won’t be worth
adding the complexity of having a User model (and code) if so, but if
other user types need to login in the future, the Owner model will have
to be refactored to move the User behavior into a separate model.
Cody S. wrote:
bingo bob wrote:
an owner has many properties and a property belongs to an owner. I store
lots of things in the owner table including login information, notes as
Will owners ALWAYS be the only users logging in? It won’t be worth
adding the complexity of having a User model (and code) if so, but if
other user types need to login in the future, the Owner model will have
to be refactored to move the User behavior into a separate model.
As it stands, owners are users (same thing, I keep the logins and
passwords in the owners table). My admin is for example an owner…just
one without any properties. I basically just make the admins a special
type of owner - i used acts_as_authenticated and just added stuff to the
users model and changed it’s name to owners.
Thanks for this yesterday.
I’m there I think on the model setup and such like, the belongs to and
has many relationships are in place and the property_id column. The
action after the create is there in my payments model with dummy code
for the time being.
Trouble is, I can’t see how to implement this in my controllers…
I generated a scaffold for payments, ./script/generate scaffold payment,
which clearly gives me a payments controller with CRUD actions and the
views for these.
Trouble is, I can’t quite see where I make the link between the property
and payment (I mean I’ve done it in the models but I need to tell the
payment which property the payment is for when I create or update)?
If anyone can provide a simple example of some controller code to add a
payment to a property I would be very grateful.