how would you access that attribute (rowstate), if you don't have a model for it?
what exactly do you mean by "softdelete"? why not leave it to rails to delete the rows whenever you unaasign a user from a profile?
MaD wrote:
how would you access that attribute (rowstate), if you don't have a model for it?
what exactly do you mean by "softdelete"? why not leave it to rails to delete the rows whenever you unaasign a user from a profile?
I dont want to delete any rows from the mapping table as,
considering from performance point of view, deleting will take more
time than updating.
So , whenever i unassign a person from a profile, i'll just update the
rowstate as "deleted". My requirement is that.
I know that we cant access the extra attribute without a model. As i'm a
fresher in rails i just wanted to know if there is a way to do that.
Thanks 
Preethi Sivakumar wrote:
I dont want to delete any rows from the mapping table as, considering from performance point of view, deleting will take more time than updating.
But you will be creating more work and time in managing changing the state of the join instead ?
I would classify this as _severely_ premature optimising. Unless you are very regularly removing thousands of profiles from thousands of users this is a mad design decision.
I'd question your theory that deleting a row from a join table is significantly slower than updating a status on it also. Having a status means that status will need to be part of both foreign keys' indexes as you will be accessing the join with a condition on the status. This will add an "overhead" - ignoring the extra work you are going to have to do in all your automatic associations.
Andrew Porter wrote:
Preethi Sivakumar wrote:
I'd question your theory that deleting a row from a join table is significantly slower than updating a status on it also. Having a status means that status will need to be part of both foreign keys' indexes as you will be accessing the join with a condition on the status. This will add an "overhead" - ignoring the extra work you are going to have to do in all your automatic associations.
I was in an impression that updation takes less time than deletion. I'm getting ur point now. Could you please elobarate on this point so that i could proceed with the idea of deletion instead of updation.
Preethi Sivakumar wrote:
I was in an impression that updation takes less time than deletion. I'm getting ur point now. Could you please elobarate on this point so that i could proceed with the idea of deletion instead of updation.
Instead of accessing user.profiles (as simply as that) you are going to always have to introduce a condition (or use named_scopes but ultimately the same condition is there). This is complicated more so because your condition needs to test a column on the join table so you are going to be hand crafting all your finds to reference the status column.
If you are accessing a table via user_id and status regularly it makes sense to index your join table on (user_id, status) and possibly also on (profile_id, status). This probably adds more overhead than a delete would on a simpler table because changing the status will result in 2 index updates. Deletes aren't that expensive.
Get your rails application working using rails' conforming techniques first. Worry about problems when they occur. And don't optimise early