Jason,
Just to clarify, the same address can be associated to both a set of
users and a set of companies, so if I change the address for company
A, that could potentially change the address for companies B and C and
users A, B and C (who presumably don't work for company A or B
otherwise you'd just get their addresses via the company)? I'm trying
to get an example of where this would happen in practice (not saying
it wouldn't, just making sure you don't have more flexibility than you
need and/or unintended side effects where company A moves out of an
office park and suddenly you've changed the address for a bunch of
unrelated companies in the same business park).
If I want work address for user A, I'm going to
UserA.getCompany().getAddress(). Only reason for separate join table
to Addresses from Users is (for example) a home address, so if userA
lived in the same building as company A it might make sense to join
both to the same address record, but even then, if the person moved
out of that building to a new apartment, would you really want that to
also move the company to that apartment automatically?
A more common modeling approach is to have (for example)
CompanyAddresses and UserAddresses tables and (honestly) usually a
1:many relationship with the CompanyAddress having a CompanyId as
usually at least the suite number is different between companies in
the same building. Similarly with a UserAddress table having a UserId
as just because two people live in the same apartment it doesn't mean
when one moves the other does. Even if they are married, divorce
happens.
You can still have an address bean for any functionality that either a
companyaddress or useraddress needs if you are worried about
duplication of any custom code.
I just want to raise this to make sure that the model is exactly what
you're looking for. A more common model might be easier to implement/
handle. That said, apologies if you've thought all this through, if
your model is exactly what you need and if you just wanted a hand with
the syntax in transfer!
Best Wishes,
Peter
On Oct 28, 2009, at 10:14 AM, Jason Durham wrote:
> I have an Address object. I also have a Company object as well as a
> User object. Both Companies and Users can have addresses. Users
> may have the same address as their company. Each Company can have
> several Users.
>
> In the "old days" of SQL, I would establish a join table between
> Company (with a FK) and Address (PK only). And a separate join
> table for User and Address. For the sake of simplicity, I'll just
> ask about the Company > Address relationship.
>
> I'm having a hard time wrapping my head around the M2M relationship
> and how a join table fits into an ORM. Logically, I'd like to ask
> the Company for its address. So, it seems that I'll need to create a
> method in my CompanyDecorator to ask the "CompanyAddresses" join
> object to retrieve its addresses? Then create new "Addresses"
> property on the Company object holding the resulting array of
> Address objects?
>
> Or... is it possible (this is when my head turns to mush) for me to
> create a o2m relationship on the Company linking to the join table?
> Then perhaps I could continue to ask down the chain of objects for
> the Address? Something like...
>
> |----------get class---------------|-----ask o2m-----|------------
> ask m2m----------|---ask for Address objects---|
> Transfer.get("my.Class",
> 45).getAddresses().getCompanyAddresses().getAddressArray()
>
> I realize that the last bit of code isn't going to work... (read
> above about "mush"), but it seems there might be a way for me to
> drill down using the supplied o2m/m2m methods. Is this true? Or
> perhaps you can't have an o2m and m2m using the same FK? I think
> read that somewhere.... So... I wouldn't mind having 2 columns with
> the same data in them (same FKs).
> --
> Jason Durham
>
>
> --
> Jason Durham
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
Before posting questions to the group please read:
http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer
You received this message because you are subscribed to the Google Groups
"transfer-dev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/transfer-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
