you know, back when I first got into Python and wrote Myghty, I got
exposed to this whole "oh no theres TOO MANY WEB FRAMEWORKS" thing
that was going on, which I suppose is still going on, and my casual,
largely uninformed impression of it was that it seemed to be a notion
spearheaded primarily by young, possibly novice developers who were
having a hard time making a decision on how to build their first
dynamic website. My opinion at that time, which hasnt changed much,
is that if the Python community made this across-the-board decision
to "dumb down" the entire community's offering to one set of lowest
common denominator tools, just to please people who either had
shallow experience and/or were too lazy to look into things deeply
and decide what worked best for them, that would be very
unfortunate. That mentality is exactly the reason (well one of
several) that I had no interest whatsoever in the Ruby community. I
had a lot of ideas which I wanted to see happen, and it was obvious
that if I had chosen Ruby, those ideas would have no audience
whatsoever; its a one-horse town.
With regards to SQLObject, I definitely looked at it and came away
with being very impressed by its operator-overloaded idea, and also a
strong sense that the notions I had for an ORM were philosophically
completely different, namely in the areas of: an ORM and SQL
construction tool that would work with databases of any
configuration, rather than the ORM dictating the specifics of the
schemas that would function; having an ORM that mapped to relational
concepts and rows instead of tables, and firmly decoupled domain
objects from their persistence implementation, rather than conflating
them for convenience; supporting and embracing the individual
abilities of databases instead of trying to distill them down to one
single "virtual database"; and a prioritization of patterns that are
acceptible to the typical DBA: aggregation and minimization of
INSERT/UPDATE operations, fully and explicitly transactionalized
behavior, full use of bind parameters, as much support for joins/
unions/eager loads as possible, allowing custom SQL to be injected
anywhere, common patterns like composite primary keys and adjacency
list structures easily supported, and a modular design allowing
important algorithms like connection pooling to be inspected and/or
swapped out.
I also could see that SQLObject had a huge following, a whole lot of
enthusiasm, and I thought that was a great thing; I can write my ORM,
get my own crowd of users (since I knew they were out there), and
then Python can have two (or more, I hear PyDO is great too) world-
class ORM's, appealing to different philosophies and crowds, possibly
engaged in a healthy competition that compelled each one to remain
vital. I continue to be confused by this notion, even though its a
central Python slogan, that having a little bit of choice is a bad
thing. Also, my target audience is seasoned professionals or those
looking to be such, who need tools that will grow with their own
needs and never be unexpectedly let down by some architectural
shortcoming, rather than those who seek something drop-dead simple
and quick at the expense of scalability and flexibility which they
believe they'll never need (or are unaware they will need). I build
my stuff in the hopes that an Ebay, Craigslist, or del.icio.us will
use my tools someday; even though Python is not so prominent in that
arena, I have hopes that it can become so. This audience is
definitely not the only audience in the Python community, and it
seems natural that different audiences may require slightly different
toolsets.
While I am not sure of the specific timing, from my perspective it
appeared that Ian's announcement of SQLApi and later SQLObject2,
which promised many of the features SQLAlchemy already had and which
formerly on the SO site had said would never be supported (the
comment about, "will probably never support composite primary keys"
and "you dont need to use LEFT OUTER JOIN" are what I am referring
to), was completely after I had already developed a large chunk of
SQLAlchemy and showed it around to a few people, im pretty sure
including Ian on the IRC channel. If SA was a catalyst in Ian's
decision to develop SO2, I'd say that's evidence that SA already had
a massively positive effect on the SQLObject community, and I look
forward to the overall improvement of toolset availability within the
Python domain.
- mike
On Mar 18, 2006, at 12:35 PM, Alan Franzoni wrote:
Hello! I hope this message may help. I'm an ex-SQLObject user and now
SQLAlchemy user. I just read on the SO group that sqlobject 0.x is
being
dropped and a probably backwards incompatible SQLObject 2 is being
developed.
I think SQLAlchemy is more complex but more coherent, and the recent
ActiveMapper function allows any easy, more SQLObject-like database
schema
definition, and in fact I think it was created after SO behaviour.
Now, my 2c: do we really need *two* ORMs in the Python community? I
think
it's not easy to create an ORM, and dividing two skilled
programmers into
two different projects will probably mean that development will be
slower.
Multiple unfinished project on the same subject and zero stable-and-
usable
software in the same category is already a common issue in the open
source
community, we should not make it worse.
There're various SO2 features I'd like to see in SA, mostly related
with
SQLobject ease-of-use - in SA everything can be done by creating an
appropriate object, but SQLObject often does it 'out of the box' (e.g.
column overrides).
It would be nice to have a kind of SQLObject class to inherit from in
SQLAlchemy, or something similar. Haven't you (Ian and Micheal) ever
considered a merge?
Please note: I don't want to give unwanted advice. I'm not a skilled
programmer, but I just think there're toooo many 'in progress'
software
doing the very same thing in the open source world, and that wastes
a lot
of programming time, and often it's not the worse software to reach an
'unmantained' state in the end.
Bye!
--
Alan Franzoni <[EMAIL PROTECTED]>
-
Togli .xyz dalla mia email per contattarmi.
Rremove .xyz from my address in order to contact me.
-
GPG Key Fingerprint:
5C77 9DC3 BD5B 3A28 E7BC 921A 0255 42AA FE06 8F3E
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
that extends applications into web and mobile media. Attend the
live webcast
and join the prime developer group breaking into this new coding
territory!
http://sel.as-us.falkag.net/sel?
cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
