Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] Object relational mappers

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Chad Knepp <pyg@galatea.org>
  • To: pcplantdb@lists.ibiblio.org
  • Subject: Re: [pcplantdb] Object relational mappers
  • Date: Sun, 29 Aug 2004 14:36:59 -0500

Richard Morris writes:
> Chad Knepp wrote:
> > I've spent most of the day looking at Object - Relational Mappers for
> > python (ORMs) (great link:
> > <http://www.thinkware.se/cgi-bin/thinki.cgi/ObjectRelationalMappersForPython>)
> > and like SQLObject and Ape (Zope lives on) pretty well although if we
> > do go the RDBMS way I think we might want to roll our own in this case
> > because the more general approaches taken by most of these ORMs is
> > clunkier than it needs to be for our more specialized/narrow needs.
> > Anyway I'm beginning to think that a pure OO approach will be almost
> > necessary for a sane implementation of Relationships and this is the
> > way to turn an RDBMS into an ODBMS. PosgreSQL bills itself as an
> > ODBMS although I haven't looked into it yet.
> >
>
> Well there is the canonical OO - RDB mapping.
>
> For each object type, create a table. For each member of the
> object create a field. If the member is an array
> create a new table which uses the id of parent object as a key.
> If the member is an object use id of the object as field value.

Yep. The reason to use an ORM is that after you've written it all of
the rest of your code appears to be pure OO. Also the automation of
table creation inserts, deletes, updates, and selects with a nice
friendly API is going to 1) be more fun than SQL and 2) save time.

> Hence
>
> Class BotName
> String Genus
> String Species
> String Author
>
> Class Plant
> BotName acceptedName
> Array of BotNames synonyms
> Float height
>
> we have
>
> Table BotNames
> id (int Primary Key)
> Genus (Text not null)
> Species (Text)
> Author (Text)
>
> Table Plants
> id (int Primary Key)
> acceptedName (int) -- used as index for BotName table
> height (float)
>
> Table PlantSynonyms
> plantId (int) -- reference to plant
> nameId (int) -- refetrence to name

Sure, but with something Class BotName extends SimpleORM you can
pretty much lose all the SQL.

> Now if we want to have objects which can have extensible
> properties, ie. defined at run time rather than compile time:
> which seems to be the main thing zope offers
> this can be easily modeled.
>
> Table PlantProperties
> plantId (int) -- reference to plant
> propertyName (string) -- contains the name of the property
> propertyValue (string) -- actual value of property
>
> can be modified to work with other types for propertyValue.

This aspect could also be abstracted by an ORM.

--
Chad Knepp
python -c 'import base64;print base64.decodestring("cHlnQGdhbGF0ZWEub3Jn")'




Archive powered by MHonArc 2.6.24.

Top of Page