Django Vs Rails

[flamesrock]

Firstly, this topic is NOT intended for trolling or starting any flame
wars.

I want to know if anyone has experience with these frameworks, and if
so, how do they compare? Which one do you prefer?

Going back to school in a few days, I simply don't have the time to try
both.

-thanks
http://djangoproject.com
http://rubyonrails.com

[Jonathan Ellis]

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

-Jonathan

[Jacob Smullyan]

On 2005-09-15, Jonathan Ellis <jb*****@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

[Jorge Godoy]

Jacob Smullyan <sm******@smull yan.org> writes:

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.

I just wonder when it becomes bad having to declare everything. For example,
we have databases with 600 tables. Declaring them all again will make a huge
PITA and would not be very helpful, specially because there's already some
declarations at the ER diagrams, at the SQL script, inside the database, and
then again at each and every python class?

Having the introspection is great in this case (even though it is boring
having to declare all those classes and tell them to fetch their structure
from the database it is better than having to "recreate" all of them).

With regards to failures, this is one of the reasons for unit tests :-) They
can help finding out where is the problem and they should never fail
silently.

--
Jorge Godoy <go***@ieee.org >

[Jacob Smullyan]

On 2005-09-15, Jorge Godoy <go***@ieee.org > wrote:

I just wonder when it becomes bad having to declare everything. For example,
we have databases with 600 tables. [snip] Having the introspection is great in this case (even though it is boring
having to declare all those classes and tell them to fetch their structure
from the database it is better than having to "recreate" all of them).
Granted. Also, if the tables share structure, another option would be
to simplify their description with inheritance.
With regards to failures, this is one of the reasons for unit tests :-) They
can help finding out where is the problem and they should never fail
silently.

You are right. I am consoled.

js

--
Jacob Smullyan

[Jorge Godoy]

Jacob Smullyan <sm******@smull yan.org> writes:

Granted. Also, if the tables share structure, another option would be
to simplify their description with inheritance.

It would be great if relationships could be mapped this way too. Something
like ...

=============== =============== =============== =============== =============== =====
class Person(baseclas sForORM):
pk_person = PK() # Dunno, it could be anything...
name = String(40)
birth_date = Date()
sex = String(1)
obs = Text()
Address(basecla ssForORM):
pk_address = PK() # Dunno, it could be anything...
person_pk = Person(pk_perso n) or None # If it can be null...
city = String(30)
state = String(30)
(...)

inhabitant = ''
if (addressInstanc e.person_pk):
inhabitant = address.name

(...)

=============== =============== =============== =============== =============== =====

(this is a *very bad* example, I just couldn't think of
something simple and better right now)

.... would also be interesting but it isn't essential. I believe it is simpler
than inheritance for the ORM tool. Just making it easy to retrieve records
from a related "class" would be great. This is one thing that I like with
SQLObject -- I have never used PyDO, but I'll give it a try -- and getters and
setters :-)

When you go to the field of ORDBMS, it gets even more complicated, since you
can have inheritance on the database side as well...
Ah! Of course one should not forget of mapping views as well. :-) Having
some way to create logic to update the view is nice if the selected database
doesn't support it (e.g. with rules when using PostgreSQL).
But then, I'm far out of Python with this message :-) Sorry.

--
Jorge Godoy <go***@ieee.org >

[maluke]

I'm a python guy, so I haven't tried rails myself (I did read the
tutorial though). I tried Django and didn't like it somewhat. One thing
I don't like about it is that you have to write the same things twice,
for ex. specify url resolver and reference it in config. Django is not
bad but not spectacular either. http://www.turbogears.org/ on the other
hand is! I had no CherryPy or SQLObject experience before, but I learnt
the framework and implemented my first web-app with it in one day time!
That includes the model, some views and an xml-rpc control interface.
That's outstanding productivity if you ask me.

You should give TurboGears a try.

[Jaroslaw Zabiello]

Dnia 24 Sep 2005 22:48:40 -0700, ma****@gmail.co m napisa³(a):

You should give TurboGears a try.

http://www.turbogears.org/about/status.html

"TurboGears should be considered *alpha* software. This means that there
can be *breaking API* changes between now and 1.0." It uses CherryPy
(beta!), SQLObject (beta) and Kid (which has a couple of bugs that need
fixing) This project is good only for fun and playing not for enterprise.

--
JZ

[D H]

Jaroslaw Zabiello wrote:

Dnia 24 Sep 2005 22:48:40 -0700, ma****@gmail.co m napisa³(a):

You should give TurboGears a try.

....This project is good only for fun and playing not for enterprise.

That's my kind of project :)

[Luis M. Gonzalez]

If you are looking for something pythonic, full featured and very easy
to use, you should check this out: http://karrigell.sourceforge.net

Give it a try and let me know how it goes...

Cheers,
Luis