I didn't mean mapping Root to a Table (if not necessary) is my intent,
what I'd like to know is how to get the same behavior without the
bloat of an extra table.
> make your application work a certain way (where "certain way" here is not
> clear)
I make an example, maybe I'm wrong tho:
let's say I delete an item, I'd expect not to find this item anymore
in its (ex) parent items
>>>subarea.items
[<item>]
>>>session.delete(subarea.items[0])
>>>session.commit()
>>>subarea.items
[]
This would be not the same for root's areas if I just use a query
>>>root.areas = query(Area).all()
>>>root.areas
[<area>]
>>>session.delete(root.areas[0])
>>>session.commit()
>>>root.items
[<area>]
I hope I has been able to focus on my question now.
Thanks for your help
neurino
On Nov 15, 9:57 pm, Michael Bayer <mike...@zzzcomputing.com> wrote:
> 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
> > 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.
