On Nov 15, 2010, at 10:46 AM, neurino wrote:
> Thanks for your answer first.
>
> Root is a singleton, its class is not mapped to a table.
>
> What I mean is I could add a table "roots" to the database with a
> sigle row and add areas a foreign key "root_id" and create a
> relationship as from subareas with parent area and get what I'm
> talking about.
sure, then you're mapping Root to a table, and having just one row. That
would make Root.area act exactly like a relationship() though its a little
strange to have a row in the database just to make your application work a
certain way (where "certain way" here is not clear).
>
> This relationship, between root and area, as long as areas and
> subareas would come in handy for example to traverse the tree for
> extracting an xml simply, or to make recursive calculations.
>
> Before sqlalchemy I was used to add all areas, subareas, items, parent
> attributes to classes by myself but now I'm in the situation that 80%
> of the work is done by sqlalchemy automatically and I'm not sure how
> to fill the remaining, possibly having both areas and subareas behave
> at the same way to avoid confusion (just as an example, lazy loading).
>
> Thanks for your support
> neurino
>
> On Nov 15, 3:49 pm, Michael Bayer <mike...@zzzcomputing.com> wrote:
>> On Nov 15, 2010, at 8:06 AM, neurino wrote:
>>
>>> So no advice?
>>
>>> Are relationships and backref something more than attributes I can
>>> setup with a query?
>>
>>> Thank you for your support.
>>
>> what's not stated clearly here is what "Root" is. If that's not a class
>> mapped to a table, then you'd just need to use regular Python attributes and
>> descriptors to establish the in-python behavior you're looking for. Seems
>> like its essentially some kind of query object, so your query.all()/.parent
>> = some_root approach is what you'd go with, though it would appear that Root
>> is a singleton anyway, meaning this could be established on Area at the
>> class level instead of assigning to each instance.
>>
>> Its not clear what other behavior of "relationship()" would apply here,
>> since Root has no database identity.
>>
>>
>>
>>
>>
>>> On Nov 11, 9:45 am, neurino <neur...@gmail.com> wrote:
>>>> I have a tree structure
>>
>>>> Root
>>>> |
>>>> +--Area
>>>> | |
>>>> | +--SubArea
>>>> | | |
>>>> | | +--Item
>>>> | | |
>>>> | | +--Item
>>>> | |
>>>> | +--SubArea
>>>> | |
>>>> | +--Item
>>>> | |
>>>> | +--Item
>>>> |
>>>> +--Area
>>>> |
>>>> +--SubArea
>>>> | |
>>>> | +--Item
>>>> | |
>>>> | +--Item
>>>> |
>>>> +--SubArea
>>>> |
>>>> +--Item
>>>> |
>>>> +--Item
>>
>>>> The tree structure corresponds to slqalchemy db tables `areas`,
>>>> `subareas` and `items`.
>>
>>>> Something like this:
>>
>>>> mapper(Area, areas_table, properties={
>>>> 'subareas': relationship(SubArea, backref='parent'),
>>>> })
>>>> mapper(SubArea, subareas__table, properties={
>>>> 'items': relationship(Item, backref='parent'),
>>>> })
>>>> mapper(Item, items_table)
>>
>>>> so each Area instance will have a `subareas` list and each SubArea
>>>> will have a `items` list,
>>
>>>> also I easyly get a backref `parent` from Item to parent SubArea and
>>>> from
>>>> SubArea to parent Area.
>>
>>>> But this won't be for Root: it will not have a `areas` list in Root
>>>> nor its areas will have a parent reference to Root.
>>
>>>> The quick-and-dirty solution is to do this in Root:
>>
>>>> self.areas = query(Area).all()
>>>> for area in self.areas:
>>>> area.parent = self
>>
>>>> But it won't be the same thing as sqlalchemy `relationship` attributes
>>>> so:
>>>> are there alternative solutions more sqlalchemy-like?
>>
>>>> Any tip appreciated!
>>
>>>> Thank you for your support
>>
>>>> Greetings
>>>> neurino
>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "sqlalchemy" group.
>>> To post to this group, send email to sqlalch...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> sqlalchemy+unsubscr...@googlegroups.com.
>>> For more options, visit this group
>>> athttp://groups.google.com/group/sqlalchemy?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sqlalchemy" group.
> To post to this group, send email to sqlalch...@googlegroups.com.
> To unsubscribe from this group, send email to
> sqlalchemy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sqlalchemy?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
