Django Vs Rails

[flamesrock]

Re: Django Vs Rails

Wow- thanks for all of the replies. I'm torn.

On the one hand, I'm fluent in Python and love it.

On the other, Rails seems to have a brighter future, and is a bit more
featureful (at this time.) However the only Ruby I know is what I've
already learnt with Python(even though I would like to learn it).

How difficult would it be to learn Ruby+Rails, assuming that someone is
already skilled with Python?

Is it worth it?

[James]

Re: Django Vs Rails

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.

[Marek Kubica]

Re: Django Vs Rails

Hello!

On 7 Sep 2005 20:56:28 -0700 flamesrock wrote:
[color=blue]
> On the other, Rails seems to have a brighter future,[/color]
Why that? Django is not yet released and everybody is talking about it.
Like it happened with RoR.
[color=blue]
> How difficult would it be to learn Ruby+Rails, assuming that someone is
> already skilled with Python?[/color]
Learning Ruby: quite trivial, as Ruby is like Python, but sometimes there a
Ruby-way and a non-Ruby-way (codeblocks and stuff like this) and to write
nice Ruby programs you better write in the Ruby-way.
[color=blue]
> Is it worth it?[/color]
Well, I've learned it, because it was easy but I haven't yet found a really
significant difference that makes Ruby much better than Python. You can
write some things in an very elegant way, but sometimes the Python solution
is more readable. But the docs are sometimes.. say: very compact ;).
As Ruby is not that hard to learn you could give it a try - maybe you'll
like it, maybe not.

RoR is not the only framework, some folks prefer Nitro.

greets,
Marek

[Ian Bicking]

Re: Django Vs Rails

Diez B. Roggisch wrote:[color=blue]
> - rails/subway reflect over a existing table. They create OR-mappings
> based on that. You only specify exceptional attributes for these mappings.
>
> - django specifies the whole meta-model in python - and _generates_
> the SQL/DDL to populate the DB. So obviously you have to be more verbose
> - otherwiese you won't have the fields you need.[/color]

Subway is built on SQLObject, and SQLObject can both create tables and
read schemas from an existing database. I don't know what style is
preferred at the moment in Subway, but personally I always create my
tables with SQLObject because I always end up enumerating all the
features of the tables eventually anyway.

[Jeff Shell]

Re: Django Vs Rails

My opinion, as posted there, was pretty immediate and only going off of
surface values. I just saw in Django what I had seen too much of in my
own code. I've written similar things in Zope and Formulator that did
all sorts of fancy automatic 'admin screen' generation, DBMS CRUD
statements. I even applied those same tricks to LDAP with some success.
So some of what I saw with Django reminded me of code that I both loved
and hated - it made my data management work easy, but it was ugly and
hard to navigate and maintain, and I could never remember even my own
shortcuts and options of what to have in my nested dictionaries and
lists and tuples that defined all of these structures.

It was also an all-too-quick response in that I perceived, wrongly,
that Django was another Rails clone. I was quickly corrected on this,
and believe I posted a correction later. As I've said in some other
posts on my site - I don't really care much for the Python "Web
Frameworks" which go off and try to mimic the technology of the day.
I've been through competing with Perl, with Servlets, with J2EE, with
PHP/ASP, and now with Rails, and just about every implementation I've
seen of these has been underwhelming, to say the least. I myself am
guilty of writing an early WebObjects inspired toolkit back in '96.
Django is its own thing, and I give it credit for that. Some recent
changes to the Django model syntax make it more palatable to my tastes,
but I doubt that I'll personally be leaving Zope 2 or 3 for any of
these systems any time soon. Zope / Principia / Bobo have all served me
well for nearly a decade now, and Zope 3 makes ZODB based Zope
development so easy and powerful that I hope to never have need of an
ORM system again. These ORM tools like SQLObject and ActiveRecord still
seem best suited for writing applications from scratch. Ian Bicking and
Django people both have stated here that you can "convenient ly generate
SQL/DDL to populate the DB". If that's the situation, an object
database like the ZODB or Durus may work just as well, without the
translation to SQL and back. ORM only gets interesting to me these days
when I have to map to to large scale pre-existing systems, and even
there I'm having better experiences with other styles of storage to
application data translation, validation, security, and management.

[Jonathan Ellis]

Re: Django Vs Rails

James wrote:[color=blue]
> 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.[/color]

PyDO (http://skunkweb.sourceforge.net/pydo2.html) is a Python ORM tool
that does this well (*cough* better than sqlobject *cough*).

-Jonathan

[Jacob Smullyan]

Re: Django Vs Rails

On 2005-09-15, Jonathan Ellis <jbellis@gmail. com> wrote:[color=blue]
> James wrote:[color=green]
>> 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.[/color]
>
> PyDO (http://skunkweb.sourceforge.net/pydo2.html) is a Python ORM tool
> that does this well (*cough* better than sqlobject *cough*).[/color]

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]

Re: Django Vs Rails

Jacob Smullyan <smulloni@smull yan.org> writes:
[color=blue]
> 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.[/color]

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 <godoy@ieee.org >

[Jacob Smullyan]

Re: Django Vs Rails

On 2005-09-15, Jorge Godoy <godoy@ieee.org > wrote:[color=blue]
> I just wonder when it becomes bad having to declare everything. For example,
> we have databases with 600 tables.[/color]
[snip][color=blue]
> 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).[/color]

Granted. Also, if the tables share structure, another option would be
to simplify their description with inheritance.
[color=blue]
> 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.[/color]

You are right. I am consoled.

js

--
Jacob Smullyan

[Jorge Godoy]

Re: Django Vs Rails

Jacob Smullyan <smulloni@smull yan.org> writes:
[color=blue]
> Granted. Also, if the tables share structure, another option would be
> to simplify their description with inheritance.[/color]

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 <godoy@ieee.org >

[maluke@gmail.com]

Re: Django Vs Rails

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]

Re: Django Vs Rails

Dnia 24 Sep 2005 22:48:40 -0700, maluke@gmail.co m napisa³(a):
[color=blue]
> You should give TurboGears a try.[/color]

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]

Re: Django Vs Rails

Jaroslaw Zabiello wrote:[color=blue]
> Dnia 24 Sep 2005 22:48:40 -0700, maluke@gmail.co m napisa³(a):
>
>[color=green]
>>You should give TurboGears a try.[/color]
>
> ....This project is good only for fun and playing not for enterprise.[/color]

That's my kind of project :)

[Luis M. Gonzalez]

Re: Django Vs Rails

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