[Grok-dev] Modeling a class that extend from list() with megrok.rdb
Jeffrey D Peterson
bgpete at gmail.com
Wed Oct 27 16:17:56 EDT 2010
--
Jeffrey Peterson
bgpete3 at gmail.com
> -----Original Message-----
> From: grok-dev-bounces at zope.org [mailto:grok-dev-bounces at zope.org] On
> Behalf Of Hector Blanco
> Sent: Wednesday, October 27, 2010 2:31 PM
> To: grok-dev at zope.org
> Subject: Re: [Grok-dev] Modeling a class that extend from list() with
> megrok.rdb
>
> 2010/10/27 Jeffrey D Peterson <bgpete at gmail.com>:
> > I am a little confused to what you are trying to accomplish.
> >
>
> I know... I understand. I'm sorry I can't explain myself better... But
> as I realized by reading your reply, you got it perfectly right :-)
>
> > Maybe it would be better to define what you need it to do, and model
> that
> > vs. trying to equivocate things class by class, I realize you want to
> save
> > code but you are converting from object data to relational data, they
> aren't
> > always converted easily.
> >
>
> Yeah, I know... "If it can't be done, it can't be done."
>
> > Extrapolating from what you have shown us it seems you are storing
> MyEntry
> > objects in extended python lists, correct? I assume, that these
> lists are
> > stored in the ZODB for persistence.
> >
>
> Exactly.
>
> > Now with relational data you essentially get back a list of
> dictionaries,
> > right? Rows of key-value pairs. With SQLAlchemy you can change that
> a
> > little to where you wind up with essentially a list of objects, where
> each
> > row is an object and the key-value pairs are properties of the
> object.
> >
>
> Yes. Actually, I got that working that way in some other places, where
> the "container" was just a regular python list() object.
>
> Like... I don't know...
>
> whatever_to_items = Table(
> "whatever_to_items",
> metadata,
> Column("whatever_container_id", Integer,
> ForeignKey("whatever_containers.id")),
> Column("item_id", Integer, ForeignKey("items.id"))
> )
>
> class WhateverContainer(rdb.Model):
> rdb.metadata(metadata)
> rdb.tablename("whatever_containers")
> items = relationship("Item", secondary=whatever_to_items,
> backref="whatever_containers")
>
> class Item(rdb.Model):
> """Set up items table in the database"""
> rdb.metadata(metadata)
> rdb.tablename("items")
>
> id = Column("id", Integer, primary_key=True)
>
> That works fine. The thing is that in this case, the relationship
> needs to be handled by one of my classes (The MyContainer() class)
> which, if I understood properly, also needs to be stored in the
> database (and therefore it needs to extend from rdb.Model and having
> its own id, right?) And that extension from rdb.Model is what messes
> up with my class (which, until the moment, it was happily) extending
> from list()
> :-)
>
> > In each case, your "entries" are contained in a list. With
> SQLAlchemy you
> > are closer as it's a list of objects, _and_ you can write methods
> easily to
> > access the objects.
> >
> > If it needs to be sorted out into multiple named containers, then you
> need
> > to add that wrinkle, by adding a container id to the entry object and
> either
> > managing that by hand or by maintaining a table of container IDs
> >
> > So either you'll end up with a query that looks at a container table
> and
> > joins the entries or you'll have an entries table that you can query
> for
> > only certain entries based on a container ID
> >
> > This is what I think you are getting at, am I even close?
> >
>
> Yes, you're perfectly right. As I mentioned, I have successfully
> modeled
> raw "lists" as relationships with foreign tables. This one is
> problematic because it is not exactly a list() (in the Python
> "sense"). It is a list with a bunch of special methods. That's what
> I'd like to keep but, if it can't be done, it can't be done.
>
> Maybe I will try the:
>
> class MyContainer(rdb.Model):
> def __init__(self):
> self._list = list()
> I'm sure that will save me a lot of headaches...
You can have whatever class you like in python and keep the items in a list
inside that data structure, but if they are stored in MySQL, you are getting
them and putting them with sql.
class WhateverContainer(rdb.Model):
.
.
.
def get_items(self, container_id):
return rdb.Session().query(self.items).filter(self.id ==
container_id).first().items
double check the results of first(), I can't remember if you get the object
or a list with one object. In which case it's be:
...).first()[0].items
class MyClass(object)
def __init__(self):
self._list = WhateverContainer().get_items(<container_id>)
or something to that effect.
>
> Thanks for not giving up! :-) I'll keep you posted.
>
> > --
> > Jeffrey Peterson
> > bgpete3 at gmail.com
> >
> >
> >> -----Original Message-----
> >> From: grok-dev-bounces at zope.org [mailto:grok-dev-bounces at zope.org]
> On
> >> Behalf Of Hector Blanco
> >> Sent: Wednesday, October 27, 2010 9:06 AM
> >> Cc: grok-dev at zope.org
> >> Subject: Re: [Grok-dev] Modeling a class that extend from list()
> with
> >> megrok.rdb
> >>
> >> Oh, now I see what you meant. Thanks!
> >>
> >> But there's still a problem (sorry, I'm really new to this and I may
> >> have the concepts wrong):
> >>
> >> The class I want it to attack the "my_containers_table" table is
> >> class MyContainer(list)
> >> which currently extends from list (not rdb.Model).
> >>
> >> Is there a way to have both functionalities? Do I have to go to
> >> multiple inheritance? ( class MyContainer(list, rdb.Model) ).
> >> Wouldn't that be "dangerous"? (I have been thought to avoid multiple
> >> inheritance as the plague).
> >>
> >> Do I have to do something like:
> >> class MyContainer(rdb.Model):
> >> def __init__(self):
> >> self._list = list()
> >>
> >> and use that self._list to store the data?
> >>
> >> Thank you for your help!
> >>
> >> 2010/10/26 Jeffrey D Peterson <bgpete at gmail.com>:
> >> >
> >> >
> >> > --
> >> > Jeffrey Peterson
> >> > bgpete3 at gmail.com
> >> >
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> https://mail.zope.org/mailman/listinfo/grok-dev
More information about the Grok-dev
mailing list