object-relational mappers

I've been poking around the world of object-relational
mappers and it inspired me to coin a corellary to the
the famous quote on regular expressions:

"You have objects and a database: that's 2 problems.
So: get an object-relational mapper:
now you have 2**3 problems."

That is to say I feel that they all make me learn
so much about the internals and features of the
O-R mapper itself that I would be better off rolling
my own queries on an as-needed basis without
wasting so many brain cells.

comments?

-- Aaron Watters

===
[url]http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=mild+exponential+growth[/ur
l]

On Apr 1, 1:40 pm, Aaron Watters <aaron.watt...@gmail.com> wrote:
> I've been poking around the world of object-relational
> mappers and it inspired me to coin a corellary to the
> the famous quote on regular expressions:
>
> "You have objects and a database: that's 2 problems.
> So: get an object-relational mapper:
> now you have 2**3 problems."
>
> That is to say I feel that they all make me learn
> so much about the internals and features of the
> O-R mapper itself that I would be better off rolling
> my own queries on an as-needed basis without
> wasting so many brain cells.
>
> comments?
>
>    -- Aaron Watters
>
> ===http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=mild+exponenti...[/color
]

You're going to have to learn how any of the OR mappers work to get
anything reasonable out of them, and you are going to need to commit
and invest the time to learn how one works. I would argue that you
should try making a prototype using one or two OR mappers (or just use
SQLAlchemy/Elixir and be done with it) with your existing database and
see which most efficiently does what you need it to. If you get to the
point where the queries are getting too complex to reasonably manage
as python code, then yeah, use raw SQL because that is what it's good
for. Most OR mappers will allow you to sprinkle in raw SQL as needed.

I think it's natural to be paralyzed by all the choices you have, but
just start writing some code and go from there.

Aaron Watters  <aaron.watters@gmail.com> wrote:
> I've been poking around the world of object-relational
> mappers and it inspired me to coin a corellary to the
> the famous quote on regular expressions:

> "You have objects and a database: that's 2 problems.
> So: get an object-relational mapper:
> now you have 2**3 problems."

> That is to say I feel that they all make me learn
> so much about the internals and features of the
> O-R mapper itself that I would be better off rolling
> my own queries on an as-needed basis without
> wasting so many brain cells.

That is the conclusion I have come to.

When a difficult question comes up, you end up having to know the exact
requirements and behaviour of the underlying database anyway. Then once
you know what sequence of commands you need to be issued, you have to
figure out how to persuade the ORM to do it (and not something similar
but subtly wrong). At this stage it's getting in your way.

-M-

On Apr 1, 5:40 pm, Aaron Watters <aaron.watt...@gmail.com> wrote:
> I've been poking around the world of object-relational
> mappers and it inspired me to coin a corellary to the
> the famous quote on regular expressions:
>
> "You have objects and a database: that's 2 problems.
> So: get an object-relational mapper:
> now you have 2**3 problems."
>
> That is to say I feel that they all make me learn
> so much about the internals and features of the
> O-R mapper itself that I would be better off rolling
> my own queries on an as-needed basis without
> wasting so many brain cells.
>
> comments?

Try Rails' ActiveRecord. Your problems should reduce to (lg lg
2)^(1/12).

Seriously, you'll forget there's a relational database below. (there
are even intefaces for "relational lists", "trees", etc.)

I won't post a code sample here, it would be heretic.

:-)

>
>    -- Aaron Watters
>
> ===http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=mild+exponenti...[/color
]

hdante a écrit :
> On Apr 1, 5:40 pm, Aaron Watters <aaron.watt...@gmail.com> wrote: 
>
>  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.

>  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...).

Aaron Watters a écrit :
> I've been poking around the world of object-relational
> mappers and it inspired me to coin a corellary to the
> the famous quote on regular expressions:
>
> "You have objects and a database: that's 2 problems.
> So: get an object-relational mapper:
> now you have 2**3 problems."
>
> That is to say I feel that they all make me learn
> so much about the internals and features of the
> O-R mapper itself that I would be better off rolling
> my own queries on an as-needed basis without
> wasting so many brain cells.
>
> comments?

If you're ok with building your queries as raw string and handling your
resultsets as lists of tuples, then you're right, don't waste you brain
cells learning anything else than SQL and the DB-API.

Now my own experience is that whenever I tried this approach for
anything non-trivial, I ended up building an "ad-hoc,
informally-specified bug-ridden slow implementation of half of "
SQLAlchemy. Which BTW is not strictly an ORM, but primarily an attempt
at a better integration of SQL into Python. So while it may feel like
learning the inner complexities of SQLALchemy (or Django's ORM which is
not that bad either) is "wasting brain cells", MVHO is that it's worth
the time spent. But YMMV of course - IOW, do what works best for you.

>  Try Rails' ActiveRecord. Your problems should reduce to (lg lg
> 2)^(1/12).

python> (log(log(2)))**(1.0/12.0)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
ValueError: negative number cannot be raised to a fractional power

So you are saying the problems will get really complex? :)

>  Seriously, you'll forget there's a relational database below. (there
> are even intefaces for "relational lists", "trees", etc.)

My experience with this sort of thing is that it is a bit
like morphine.  It can feel really good, and in emergencies
it can save you a lot of pain.  But if you use it too often
and too seriously you end up with really big problems.

-- Aaron Watters

===
http://www.xfeedme.com/nucular/pydi...terious+objects

On Apr 2, 10:50 am, Aaron Watters <aaron.watt...@gmail.com> wrote: 
>
> python> (log(log(2)))**(1.0/12.0)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ValueError: negative number cannot be raised to a fractional power
>
> So you are saying the problems will get really complex? :)

lg(x) == log_2(x)
lg(lg(2))^(1/12) == 0. (fortunately I didn't write 3 lg's). :-P

> 
>
> My experience with this sort of thing is that it is a bit
> like morphine.  It can feel really good, and in emergencies

I don't have this much experience on either. ;-)

> it can save you a lot of pain.  But if you use it too often
> and too seriously you end up with really big problems.
>
>    -- Aaron Watters
>
> ===http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=mysterious+obj...[/color
]

On Apr 2, 8:25=A0am, hdante <hda...@gmail.com> wrote:
> On Apr 2, 8:25 am, Bruno Desthuilliers <bruno.
>
> 42.desthuilli...@websiteburo.invalid> wrote: 
> 
> 
>
> =A0Why is that so bad ?
>
> =A0"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."
> =A0(...)
> =A0"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."
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- =[/color
]
AWDWR
>
>
> 
> 
 
>
> =A0"Some object-relational mappers s 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."
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- =[/color
]
AWDWR
>
> =A0PS. 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 ]=3D '<data/>', 'code code code'
shelf[ 0.125 ]=3D '<name/>', 'castironpi'
shelf[ 0.05 ]=3D '<modifier/>', 'oddly enough'

-=3D>

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

and

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

-=3D>

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

Plus you can't have text and subnodes anyway.

On 2 Apr, 15:50, Aaron Watters <aaron.watt...@gmail.com> wrote:
>

[Quoting hdante]
 
>
> My experience with this sort of thing is that it is a bit
> like morphine.  It can feel really good, and in emergencies
> it can save you a lot of pain.  But if you use it too often
> and too seriously you end up with really big problems.

That's two candidates for quote of the w in the same thread!

I agree with those who question why you'd want to treat a relational
database like a big dictionary, and although the interface between
queries, results and program data structures can often seem quite
awkward, I've come to realise that most object-relational mappers are
solving the wrong problems: they pretend that the database is somehow
the wrong representation whilst being a fast enough black box for
holding persistent data (although I doubt that many people push the
boundaries enough to see that it's not possible to ignore all details
of such a database whilst preserving performance), or they pretend
that languages like SQL (which can be cumbersome, admittedly) are
inconvenient for querying whilst replicating a less concise mechanism
for querying using client language mechanisms.

I'm more encouraged by the idea of "query templating", which might
sound like a recipe for all sorts of problems, but if done right could
provide more effective ways of working with relational databases than
pretending that different things in the database are somehow "objects"
in the client language sense.

Paul