Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Django Vs Rails

Reply
Thread Tools

Django Vs Rails

 
 
Jonathan Ellis
Guest
Posts: n/a
 
      09-15-2005
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

 
Reply With Quote
 
 
 
 
Jacob Smullyan
Guest
Posts: n/a
 
      09-15-2005
On 2005-09-15, Jonathan Ellis <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Jorge Godoy
Guest
Posts: n/a
 
      09-15-2005
Jacob Smullyan <(E-Mail Removed)> 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 <(E-Mail Removed)>
 
Reply With Quote
 
Jacob Smullyan
Guest
Posts: n/a
 
      09-15-2005
On 2005-09-15, Jorge Godoy <(E-Mail Removed)> 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
 
Reply With Quote
 
Jorge Godoy
Guest
Posts: n/a
 
      09-15-2005
Jacob Smullyan <(E-Mail Removed)> 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(baseclassForORM):
pk_person = PK() # Dunno, it could be anything...
name = String(40)
birth_date = Date()
sex = String(1)
obs = Text()


Address(baseclassForORM):
pk_address = PK() # Dunno, it could be anything...
person_pk = Person(pk_person) or None # If it can be null...
city = String(30)
state = String(30)


(...)

inhabitant = ''
if (addressInstance.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 <(E-Mail Removed)>
 
Reply With Quote
 
maluke@gmail.com
Guest
Posts: n/a
 
      09-25-2005
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.

 
Reply With Quote
 
Jaroslaw Zabiello
Guest
Posts: n/a
 
      09-25-2005
Dnia 24 Sep 2005 22:48:40 -0700, http://www.velocityreviews.com/forums/(E-Mail Removed) 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
 
Reply With Quote
 
D H
Guest
Posts: n/a
 
      09-25-2005
Jaroslaw Zabiello wrote:
> Dnia 24 Sep 2005 22:48:40 -0700, (E-Mail Removed) 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
 
Reply With Quote
 
Luis M. Gonzalez
Guest
Posts: n/a
 
      09-26-2005
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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Question on Django and Django Book John Posner Python 0 11-13-2010 06:55 PM
Need a compelling argument to use Django instead of Rails Ray Python 96 08-18-2006 04:53 PM
Benckmarking Ruby on Rails, Django, Perl matt@e-titans.co.uk Ruby 9 04-27-2006 02:12 PM
[ANN] Rails and Django Debate John W. Long Ruby 0 11-26-2005 06:33 PM
Django - Rails killer comes... JZ Python 4 07-18-2005 11:24 AM



Advertisments