object-relational mappers

castironpi at gmail.com castironpi at gmail.com
Wed Apr 2 13:17:08 EDT 2008


On Apr 2, 8:25 am, hdante <hda... at gmail.com> wrote:
> On Apr 2, 8:25 am, Bruno Desthuilliers <bruno.
>
> 42.desthuilli... at websiteburo.invalid> wrote:
> > hdante a écrit :
>
> > >  Try Rails' ActiveRecord. Your problems should reduce to (lg lg
> > > 2)^(1/12).
>
> > Correct me if I'm wrong, but IIRC ActiveRecord requires you use numeric
> > auto_increment fields for primary key. As far as I'm concerned, this is
> > a definitive no-no.
>
>  Why is that so bad ?
>
>  "But wait !, you cry. Shouldn't the primary key of my orders table be
> the order number or some other meaningful column ? Why use an
> artificial primary key such as id ? The reason is largely a practical
> one - the format of external data may change over time."
>  (...)
>  "Normally, Active Record takes care of creating new primary key
> values for records that you create and add to the database - they'll
> be ascending integers (possibily with some gaps in the sequence).
> However, if you override the primary key column's name, you also take
> on the responsibility of setting the primary key to a unique value
> before you save a new row."
>                                    -- AWDWR
>
>
>
> > >  Seriously, you'll forget there's a relational database below.
>
> > Why on earth are you using a RDBMS if you don't want it ? I for one *do*
> > care about using a *relational* database, and *don't* want to hide it
> > away. What I don't want is to have to build my queries as raw strings.
> > And that's where SQLAlchemy shines : it's not primarily an "ORM", it's
> > an higher-level Python/SQL integration tool that let you build your
> > queries as Python objects (and also, eventually, build an ORM if you
> > want to...).
>
>  "Some object-relational mappers seek to eliminate the use of SQL
> entirely, hoping for object-oriented purity by forcing all queries
> through an OO layer. Active Record does not. It was built on the
> notion that SQL is neither dirty nor bad, just verbose in the trivial
> cases. (...) Therefore, you shouldn't feel guilty when you use
> find_by_sql to handle either performance bottlenecks or hard queries.
> Start out using the object-oriented interface for productivity and
> pleasure, and then dip beneath the surface for a close-to-the-metal
> experience when you need to do so."
>                                    -- AWDWR
>
>  PS. That's okay to use a RDBMS. What I don't want is to use two
> programming paradigms, especially, considering the "object-relational
> impedance mismatch".

I think a shelf can accomplish everything a RDMS can.  Just set up
everything as a map from a real number, remove and extract at will
(between numbers), and use XML tags.

shelf[ 0.1 ]= '<data/>', 'code code code'
shelf[ 0.125 ]= '<name/>', 'castironpi'
shelf[ 0.05 ]= '<modifier/>', 'oddly enough'

-=>

<data> code code code </data>
<name> castironpi </name>
<modifier> oddly enough </modifier>

and

shelf[ 0.1 ]= '<data/>', 'code code code'
shelf[ 0.125 ]= '<name>', 'castironpi'
shelf[ 0.05 ]= '<modifier>', 'oddly enough'

-=>

<data> code code code </data>
<name> castironpi
  <modifier> oddly enough </modifier>
</name>

Plus you can't have text and subnodes anyway.



More information about the Python-list mailing list