On Jan 9, 2007, at 6:22 PM, Hermann Himmelbauer wrote:
>
> My basic idea was to maintain the abstraction between the data
> model and the
> actual object. So the ideal place to specify such things would be
> in the
> mapper. To my mind, some "magic" with the properties could do it,
> e.g. like
> this:
>
> mapper(Person, person_table, properties = dict(
> address=relation(Address, secondary=r_pers_addrid_table,
>
> proxy_relation_attributes=True))
>
> In case "proxy_relation_attributes" is set to "True", all columns
> (except the
> foreign keys which are obsolete) are made accessible through the
> relation -
> very simple syntax.
this is just flags and switches which are specific to your use case,
and probably not many others. since SA's mappers change class
behavior by attaching properties, you should instead have some of
your own property-attaching code separately which does what you want.
> Correct me if I'm wrong, but many to many relations are normally
> done this
> way:
>
> table1 <---> association_table <---> table2
>
> table1 has a one to many relation to association_table and table2
> has also a
> one to many relation to association_table. From the perpective of
> table1, it
> should therefore in any case be possible to locate association/
> relation
> attributes along with the attributes of table2 (and the same in the
> other
> direction). The only problem could be name clashes, which could
> probably be
> handled in some way (e.g. raise an exception or prefix them).
i dont see at all why that would be the case. table1 is mapped to
class A, table2 is mapped to class B. why would the properties of A
and B want to be munged together on both classes ?
>
> This may also obsolete the "associationproxy" - but maybe I don't
> fully
> understand its concepts.
associationproxy handles the pattern where you have:
class A -> association class -> class B
you can say A.append(B) and it will automatically create instances of
the association class, and also place a collection on A which returns
instances of B without the intermediary association class instances.
also note that its a totally optional extension; no flags or switches
added to Mapper for this. Mapper is designed to do one job as simply
as possible (and its already, not that simple)..its not meant to have
any complex say in the behavior of classes. any customized behaviors
are to be in user-defined MapperExtensions, on the classes
themselves, or on some other user-defined external code.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
