[sqlalchemy] Re: relationships for no-table-related Class
Thanks Michael,
this solved most of my doubts.
Greetings
neurino
On Nov 16, 5:51 pm, Michael Bayer mike...@zzzcomputing.com wrote:
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`
[sqlalchemy] Re: relationships for no-table-related Class
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
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
[sqlalchemy] Re: relationships for no-table-related Class
So no advice?
Are relationships and backref something more than attributes I can
setup with a query?
Thank you for your support.
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.
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.
[sqlalchemy] Re: relationships for no-table-related Class
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.
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.
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.
