On Jan 13, 2006, at 3:14 AM, mike bayer wrote:
Can you give me an example of a simple task it falters with ? So far,
youve made other comments to this effect, but you havent mentioned
what
exactly is so complicated. For my part, I cant imagine how much
simpler it can be.
Let me just start out by saying that since I made my initial
impressions of sqlAlchemy, I have taken a bit more time to play with
it, and I really like it quite a bit. My issues with SQLObject are
largely technical, and sqlAlchemy seems to deal with all of those
issues quite well (simpler connection and transaction management,
less magical, better at mapping complex schemas, fewer concurrency
problems, a clearer direction, etc). I really really like
sqlAlchemy. You have done a bang-up job!
Now, on to my simple task that I find sqlAlchemy falters with:
mapping simple schemas. Its not that it can't do it, its just a
stylistic issue.
In fact, my issues with sqlAlchemy are largely stylistic. I find
SQLObject's declarative mapping to be a lot easier to read than
sqlAlchemy's insistence to separate database mapping from class
design. This aspect of sqlAlchemy feels very much like hibernate,
which I have used in the past, and found absolutely nauseating. Its
not that I don't understand the principle, or see the reasoning for
it, but most of the time I find it irritating, and more importantly,
it confuses _other people_ who read my code.
I have heard that there are some people working on a declarative
wrapper around sqlAlchemy's mapping API, and I think that this will
likely eliminate my stylistic issues.
A few people were helpful enough to make suggestions on the mailing
list, such as a "select_by" and a "get_by" method, and easier ways to
attach these methods to a class; theyve been added (as will any other
reasonable suggestion). The "select_by"/"get_by" methods are even
more powerful than typical active record "find_by" methods, while
adding zero complexity on the calling side, in that they will even
pull
in a related join if you search by a key that is not on the main class
but on one of its relations.
I noticed this as well, and it was one of my biggest gripes before!
I definitely like this change, and it shows a clear effort on your
part to make sqlAlchemy a joy to use.
Similarly, it seems that people are accustomed to saying
"foo=ForeignKey(), bar=MultipleJoin()", and are thrown off by how
these
keywords are not present in SQLAlchemy. This is an example of a
simpler approach being mistaken for a more complicated one, just
because it is unfamiliar. With SQLAlchemy, all you say is,
"foo=relation(), bar=relation()". It *figures out* the relationship
for you based on what it naturally is based on foreign keys. If you
have auto-loaded your tables from the database which has proper
foreign
key constraints, SQLAlchemy will literally automatically configure
object relations based on the database schema, with no explicit
code in
the application. Simpler ! More automatic ! Only one function to
learn instead of four or five !
I don't have a _huge_ issue with this, but playing devil's advocate
-- "explicit is better than implicit." Someone reading my SQLObject
code will easily be able to tell exactly what tables exist, which
columns exist (and what type they are), what relationships exist, and
what kind of relationships they are -- without any prior knowledge
about SQLObject.
I think that if a person with no sqlAlchemy knowledge looked at one
of my sqlAlchemy models, it would take them significantly longer to
figure out what is going on.
That being said, this isn't really a deal-breaker for me, as I can
simply comment the code to clarify any potential mapping confusion.
But it would be nice if I didn't have to ;)
Combine features like this with all the extras, like eager loading,
deferred column loading, automatic support for self-referential
tables,
and the fact that O/R complexity will increase with a relatively
smooth
correlation to the complexity of the application and database itself,
rather than making a sudden jump beyond simple cases, and SQLAlchemy
becomes even easier to live with....all for just the simple price of
looking outside the way youve been doing something all these years.
All of this is true. As I said before: you have done a great job
with sqlAlchemy. Its definitely got what it takes to handle the
simple cases, and scale all the way up to the complex ones. My
issues have nothing to do with what it can and can't do: I just wish
it was a little prettier.
I know that people are comfortable with SQLObject, and may prefer its
style. However, what I am trying to do with SQLAlchemy is make life
easier for those who understand how databases and relational
structures
work; for those people, a tool like SQLAlchemy makes simple tasks
*simpler*. And the more it allows those not accustomed to relational
structures to learn to see their database as the powerful relational
tool it is rather than a substandard object repository, the more they
will see SQLAlchemy's relational concepts making their jobs easier
than
with the object/table mappers they are used to.
I understand very well how databases and relational structures work,
and you are absolutely right that sqlAlchemy is a powerful tool in
the hands of someone like myself :) However, I work on a team, and
my code is not just for my own consumption -- its for the entire
team. At some level, I think thats the issue I have with sqlAlchemy:
its built for experts. I think its important that sqlAlchemy gives
beginners a leg-up.
There are two parts of this last part of your message that I think
are very telling.
The first is this: "what I am trying to do with SQLAlchemy is make
life easier for those who understand how databases and relational
structure work." I congratulate you on trying to make life easier
for the small number of experts, but what about beginners? There are
a lot more people that I would classify as "beginners" in this world,
and you are not targeting them very well, in my opinion.
The second is that you want people to "see their database as the
powerful relational tool it is rather than a substandard object
repository." This sounds a bit preachy to me. I have written
several extremely useful TurboGears applications using SQLObject, and
I found it to be a pleasure to use, and easy to bring other people up
to speed on. Sure, there were things that I wish it did differently,
and I had some technical problems along the way, but everyone who has
taken a look at the code immediately *gets* it. Sometimes (many
times, in fact) all you need is a substandard object repository :)
If you want to empower people, you need to get them interested
first. I am all about sqlAlchemy, and can easily see it replacing
SQLObject inside TurboGears, but not without a layer to make it a bit
more palatable. Personally, I think this is bound to happen, and I
look forward to it.
sqlAlchemy is a great piece of work, and I really don't want you to
feel like I am knocking it. I really want it to succeed!
--
Jonathan LaCour
http://cleverdevil.org
