Re: [sqlalchemy] Re: relationships for no-table-related Class
On Nov 16, 2010, at 4:19 AM, neurino wrote: 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. right so I'd just make the attribute live: Session = scoped_session(sessionmaker()) class Root(object): @property def areas(self): return Session.query(Area).all() singleton_root = Root() class Area(object): parent = singleton_root This is no different than the example above - Session.delete(someobject.collection[someindex]) does not remove the item from the collection - its only because of the call to commit() that someobject.collection is expired, and is then reloaded. If you'd like to later add caching to Root.areas such that the collection is pulled from memory until Session.commit() is called, you could enhance Root.areas to maintain values in a cache, such as a WeakKeyDictionary which uses Session().transaction as the key. 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
Re: [sqlalchemy] Re: relationships for no-table-related Class
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 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.
Re: [sqlalchemy] Re: relationships for no-table-related Class
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.