On Sep 28, 2006, at 3:27 PM, Markus Jais wrote:
> 1)
> there is code like this:
> mary2 = query.get_by(user_name='Mary') # from the docs
>
> would it be possible with python (or would it make
> sense) to write
> mary2 = query.get_by_user_name('Mary')
>
> this is the way Ruby's Active Record does it.
> don't get me wrong. I do not say that the Ruby
> approach is better or worse. I just want to understand
> why SQLAlchemy works the way it works so can write a
> very good article about it.
we do actually have that feature built into Query; it uses
__getattr__ to derive the keyname from the function called and feeds
it into the normal get_by. I added this feature early on in response
to people telling me how important that was.
However, im not thrilled about the feature and ive often considered
taking it out:
- by having get_by() as well as get_by_paramname(), we are blatantly
providing more than one way to do something without any compelling
reason (its hardly even less typing). While the Ruby community seems
to get into that Perlish attitude of TMTOWTDI (or its new name,
"humane interface"), its not as appropriate for Python.
- get_by(), while its very simple, also is a lot more powerful than
get_by_paramname() because you can feed in multiple keyword arguments
*as well* as additional SQL expressions:
query.get_by((orders.c.order_id==users.c.user_id) &
(orders.c.status='executed'), user_name='Mary', user_status='X')
Python argument: there should preferably be only one way to do it.
(granted SA breaks this rule all over the place but not without
hesitation :) )
> 2)
> another example from the docs:
> print query.select(User.c.user_id==3)
>
> would it be possible to leave out the "c" columns
> object ? maybe one could hide it inside the User
> class. example:
> print query.select(User.user_id==3)
well it would be a little tricky since User.user_id is an
InstrumentedAttribute (base class of UOWProperty), which doesnt know
anything about Columns or how its data is stored and only knows all
about the "user_id" attribute on instances of User. We could
possibly plant the sqlalchemy.sql.CompareMixin on top of it, or make
some kind of option for this to be available....that would have a
somewhat nasty interface-polluting effect on InstrumentedAttribute
which already has a lot of functionality, and would be colliding two
different areas of functionality into a single less well-defined
task. I dont think it would be great from an OO point of view and
it would limit what new features and behaviors we can give to
InstrumentedAttribute later on.
SA is not trying to do what most ORM's do, which is to try to hide
the fact that there's a database at all. SA's philopsophy is that you
can accomplish a lot more if you can make usage of relational
concepts alongside your object code. By having the "c" namespace
there, the programmer makes a conscious decision to go into
"relational selection mode" as opposed to "unsuccessfully pretend
we're an object database mode". My original decision to have "c"
was also fueled by SQLObject's usage of "q" which does not seem to
have been any impact on SQLObject's popularity.
Python argument: explicit is better than implcit.
> SQLAlchemy is by far my favourite solution for
> database programming in Python and I am happy to be
> able to write an article about it.
and I am thrilled !
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Sqlalchemy-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
