[Rails] Re: is possbile limit the number of object in has_many option?
has_one does indeed mean has a maximum of one. The belongs_to side
means has exactly one.
I don't know (because I never tried it) wjay happens if you put
"belongs_to on both sides - i.e. make something exactly 1:1. Obviously
not relevant in this case, but I could see situations where for
performance reasons you may want that kind of partition - or when
wrapping an external database.
C
On Apr 30, 1:08 pm, Rob Biedenharn
wrote:
> On Apr 30, 2009, at 1:29 PM, serenobs wrote:
>
>
>
> > thanks for replies.
> > it gives me some thought about making active record association.
>
> > then what if the man is a single?
> > husband may not have current_marriage.
> > i was thinking that has_one means it should have one object.
> > But as you know not every man will marry.
>
> > please more advice for this novice.
>
> Then, man.current_marriage will be nil as will man.wife
>
> has_one really defines a 0/1 and has_many a 0/n relation.
>
> -Rob
>
>
>
>
>
> > On May 1, 2:17 am, Rob Biedenharn wrote:
> >> On Apr 30, 2009, at 12:56 PM, Commander Johnson wrote:
>
> >>> Did you consider
>
> >>> has_one :wife
>
> >>> And in Wife.rb
>
> >>> belongs_to :man
>
> >> Or:
> >> class Wife
> >> has_many :marriages
> >> has_one :current_marriage, :class_name => 'Marriage', :conditions
> >> => { :current => true }
> >> has_one :husband, :through => :current_marriage
> >> end
>
> >> class Marriage
> >> belongs_to :wife
> >> belongs_to :husband
> >> end
>
> >> class Husband
> >> has_many :marriages
> >> has_one :current_marriage, :class_name => 'Marriage', :conditions
> >> => { :current => true }
> >> has_one :wife, :through => :current_marriage
> >> end
>
> >> -Rob
>
> >> Rob Biedenharn http://agileconsultingllc.com
> >> r...@agileconsultingllc.com
>
> >>> On Thu, Apr 30, 2009 at 6:49 PM, serenobs
> >>> wrote:
>
> >>> (my post was deleted i don't know why)
> >>> Hi. I have a question.
> >>> for example, when model records about man, suppose man can marry
> >>> with
> >>> 1 woman.
> >>> then i think code will be like this
> >>> class Man < ActiveRecord::Base
> >>> has_many: wife
> >>> end
>
> >>> Because one man can marry with up to 1 woman( 0 or 1 )
> >>> it can't be 1:1 relationship, didn't it?
> >>> but at the same time more than 1 wife is not allowed.
> >>> then how can i model this relationship into rails code?
> >>> has_many :limit option is fit for this relation?
>
> >>> Thanks.
> >>> and i wish it is not deleted again. If it should be deleted please
> >>> let
> >>> me know why it should be.- Hide quoted text -
>
> >> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~--~~~~--~~--~--~---
[Rails] Re: if...elseif...else, broken; need help
For many the observation that every operation in Ruby returns something - the primary effect, and it may do something else (a side- effect) is rather strange. So for example, we want the side-effect "put the stuff out to the printer" when we invoke puts and usually don't care about the returned value (nil). It is pretty important to separate what is returned from what it does. Sometimes they are the same (almost!), however. So == does indeed compare two comparable values, and it returns the result of that comparison (true or false). On Apr 23, 2:45 pm, Frederick Cheung wrote: > On Apr 23, 8:07 pm, DrV wrote: > > > > > > > I've been working on a new project and created a custom method for one > > of the models. Nothing major. > > > I brought up the console in --sandbox mode (also have tried in > > standard console), and tried playing with it. To my surprise there > > was a problem with the if/elseif conditional. The elseif portion > > simply would not work. So I tried a couple commands as so to test the > > actual if/elseif integrity like so: > > > person = "Jim" > > if person == "Sally" > > puts "Hi Sally" > > elseif person == "Jim" > > puts "Hi Jim" > > end > > I assume you've got elsif rather than elseif (which doesn't exist ) or > else if, which isn't the same. > > > This returns nil. > > puts always returns nil. > > Fred- Hide quoted text - > > - Show quoted text - --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~--~~~~--~~--~--~---
[Rails] Re: a client and a contractor are both users, share some attrib but not others, how to implement as users
Contnuing your theme of each column being its own table - there is some sort of merit in thinking that way - at least initially. has ittle to do with rails of course, but just as a general framework of thought. If you think conceptually about things that are hard to to in relational databases and things that are easy to do. It is, for example, much harder to add a new column than a new row to an exisiting database. So, if you have a very abstracted design like this.. Entity (entity id, entity name) Rowdata (rowdataid, domainid,entityid, colname,colvalue) Domain (domainid, domain_data_type) Then you could simply add new rows into the domain table and new rows into the Rowdata table every time you want to extend the schema. This of course is far too simplistic an approach - I have mixed the schema up with the values, so it is hopelessly unnormalized), but it sort of sets the mind off onto asking the questions about when we need ultimate flexibility vs when something just needs to work simply and quickly. The answers are never as simple as you think! However, I would also say, don't dwell on the "what might possible ne..." but implement what is most reasonable. Of course it is judgement, but when developing we always have to use our judgement. When we have made a design decision about such a thorny issue, document it so you don't have to revisit the reasons. You may have to revisit the decision, so it would be handy to know why the decision was made the way it was. I do have lots of rules (of thumb and otherwise) around this stuff - but that's how I make my living! http://businessanditarchitecture.blogspot.com C On Apr 14, 9:00 pm, Nik wrote: > Thank you vERY much, Chris! -- One often has moments where he/she > notices something that may or may not be a real worry, but is too > doubtful to speak of it. I have each of your described considerations > pulsing through my head each time I think of the future of how these > models will be in case of modification or deletion, but it was too > vague as I had no substance to fill even a hypothetical example. But > your spelling them out certainly relieved me a little. > > Having been thinking of these (potential) problems, it compelled me to > think whether there's a kind of tutorial I can read up on some rules > of thumb of deciding if table or no table and so on. I thought, a few > days, ago, that in the worst case, if I made each column its own > table, a Phone Model, a Gender Model, an Areacode Model, etc, > basically every thing would have its own model, though unrealistically > complex, it'd work ( sort of conveying that the more orthogonal bases > you have, the better; in Linear Algebra). So building up a network of > tables each holding exactly one column, I was thinking that, some > empirical/theory-based rules for combining these hypothetical single > column tables. And your Socratic method (I hope I am using this phrase > right) isn't bad, at all. > > I will discuss with my supervisor for possible scenarios that call for > minor/major table alterations, then I will begin to ask these > questions myself :) > > Thanks again! > Thank you, everyone! > > On Apr 14, 11:16 am, Chris Bird wrote: > > > > > This is a specific case of a more general problem - how to manage > > inheritance in these kinds of models. There are several things to > > think about here. However they break down fairly easily. I'll use your > > specific example, but some of the observations might not make a whole > > lot of sense. So I will pose some questions and then give some guiding > > thinking. This will not be RAILS specific thinking, but bringing > > experience from enterprise class systems where we have things like > > this all the time. You can generalize the thinking questioning when > > the structures are even deeper. > > > Which attributes are common between Clients/Contractors? > > - If there are a lot of attributes in common you might get away with a > > single table, and a type field in the table. > > > Are there relationships identified that both Clients and Contractors > > can have? > > - If for example you had a security tag table and it needed to have > > the associated "person", and it doesn't matter if the person is a > > client or a contractor, then it might be worth managing that > > relationship via a separate table (a Person table). > > > Do you expect to add new kinds of things? > > - Are Clients and Contractors the only types of Persons? Will you need > > to add something else in the future - e.g. Overseas Contractor which > > is like a Contractor but has a bunch more fields, its own processes, > > screens, etc. If so you may want to break into mul
[Rails] Re: a client and a contractor are both users, share some attrib but not others, how to implement as users
This is a specific case of a more general problem - how to manage inheritance in these kinds of models. There are several things to think about here. However they break down fairly easily. I'll use your specific example, but some of the observations might not make a whole lot of sense. So I will pose some questions and then give some guiding thinking. This will not be RAILS specific thinking, but bringing experience from enterprise class systems where we have things like this all the time. You can generalize the thinking questioning when the structures are even deeper. Which attributes are common between Clients/Contractors? - If there are a lot of attributes in common you might get away with a single table, and a type field in the table. Are there relationships identified that both Clients and Contractors can have? - If for example you had a security tag table and it needed to have the associated "person", and it doesn't matter if the person is a client or a contractor, then it might be worth managing that relationship via a separate table (a Person table). Do you expect to add new kinds of things? - Are Clients and Contractors the only types of Persons? Will you need to add something else in the future - e.g. Overseas Contractor which is like a Contractor but has a bunch more fields, its own processes, screens, etc. If so you may want to break into multiple tables. Do you expect to have a role concept that cuts across Clients/ Contractors? - Similar to relationships above, but let's imagine you also have roles like administrator, user, ... If those roles are independent of the Client/Contractor status, then again you might want separate tables. Do you have to worry about history/transition? - If a Client can become a Contractor (or vice versa) - and you need to manage the history (for example if all the timesheets haven't been cleared yet), then you will have to have something a bit more complex. Now you have to manage the temporal element when the Person can be both. There are lots of ways of doing that, none of them ideal! If you do decide to break into multiple tables, then make sure you manage the relationship handling among the tables inside the Model. Do not be tempted to put this into the Controller(s). Then you can treat the join of the Person with the Client or the Person with the Contractor as if they were individual Active Records. There will be performance penalties, but performance while important is not the only consideration. Hope this helps Chris On Apr 10, 5:42 pm, Nik wrote: > Hello All, > > I have a User Model at the moment that has only username, password, > and roles. As you might guess, I can add to the User Model a phone > column which our clients have and our contractors also have. Many > other attributes may be share by both actually. But then only a client > can have a "rate" column, and a company association and other things. > And only a contractor can have, say, an internal FTP login/password > pair. > > I don't quite know the nature of rules on deciding just how I should > do about these un-shared attributes, I know that I use the "roles" > column to differentiate a client and a contractor (learned from Raile > Recipes); should I pool all attribute into User Model anyway and then > find a mechanism to permit/forbid a client to see the contractor only > attrib and vice versa? or two other tables one being > contractor_only_properties and the other client_only_properties? I > feel that having to build a table for each role seems a bit, I am very > unlikely to be right, inflexible or at least un-easily-extensible > (sorry for making words like this). > > Your (any) opinion is very valuable to me and I thank you for spending > your time reading my problem > > All my best, > Nik --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~--~~~~--~~--~--~---
