Django Vs Rails

Jacob Smullyan smulloni at smullyan.org
Thu Sep 15 13:56:22 EDT 2005


On 2005-09-15, Jonathan Ellis <jbellis at gmail.com> wrote:
> James wrote:
>> I actually like the framework to reflect on my database. I am more of a
>> visual person. I have tools for all my favorite databases that allow me
>> to get a glance of ER diagrams and I would rather develop my data
>> models in these tools rather than in code. Further more I rather like
>> the idea of parsimonious use of code (which is probably why I use
>> Python in the first place) and do not really like manually specifying
>> data schemas in code as much as possible.
>>
>> Is some familiar with a Python Framework that builds by reflection.
>
> PyDO (http://skunkweb.sourceforge.net/pydo2.html) is a Python ORM tool
> that does this well (*cough* better than sqlobject *cough*).

As the current PyDO dev, I won't make the same comparative value
judgement as Jonathan here, not out of reticence, but lack of
conviction -- SQLObject is quite excellent, and for all I know better
than PyDO in execution -- but a comparison I would make is that PyDO
is different from ORMs like SQLObject (and even more so, from
ActiveRecord) in that it assumes that the database precedes the object
layer, chronologically and/or in significance, and that the database
schema shouldn't need to conform much to a particular ORM's
expectations, reasonable as they may or not be.  The most obvious
differences are that SQLObject expects tables to have an "id" integer
column, and doesn't support multi-column candidate keys; PyDO doesn't
make such demands.  So, similar as they are, in orientation these
libraries are somewhat different beasts.

I have mixed feelings about automagical schema introspection.  PyDO
supports it, and will probably do so increasingly robustly if people
use it.  But part of me feels that "explicit is better than implicit"
may win out over DRY here, because the ORM layer and the db layer
exist in different realms, and if the ORM layer adapts silently to
changes in the db layer, other code is likely to fail in unpredictable
ways, including silently, whereas an explicit declaration of what
fields are in a table, for instance, will fail with a hard error.  But
maybe this is anal retentiveness, akin to a need for strong typing.

js


-- 
Jacob Smullyan



More information about the Python-list mailing list