On Fri, May 4, 2012 at 12:41 AM, Massimo Di Pierro
<massimo.dipie...@gmail.com> wrote:
> Dear Tiago,
>
> No problem at all. All comments can help us improve and or give us an
> opportunity for clarification.
>
>
> On Thursday, 3 May 2012 16:04:14 UTC-5, Tiago Almeida wrote:
>>
>> Hi,
>>
>> Other than trying to start a flame war, I don't see reasons for bringing
>> my comment from the portuguese python group to here.
>> Anyway, since Anthony cared to comment I'll also comment.
>>
>> - I'm glad DAL was re-written. When I left web2py it was a mess and there
>> were many objections to touching it.
>
>
> I do not remember objections. In fact it was rewritten two years ago. It
> just took some time.
>
>>
>> - I know it does not have an orm. To me, that is a disadvantage. ORM's
>> were invented the same reason higher level programming languages were. They
>> hide details allowing people to produce more with the same effort.
>
>
> The only difference between a DAL and an ORM is that in the DAL tables are
> instances of one Table class, in an ORM each table is its own class and
> records are instances of that class. This distinction is mostly semantic. In
> our case it I believe it makes dealing with joins, aggregates, and
> combinations, more transparent. I do not believe we have any loss of
> functionality because it is a DAL and not an ORM.
>
>>
>> -The manual mapping is a consequence of not having an orm. If you have a
>> business model called Department for which there are a lot of
>> domain-specific operations you want to perform (like, say, registering
>> Teachers), you would probably declare a Python class with methods for these
>> operations. When you go to the DAL and make a select for your Department,
>> you get a Row (or whatever is called), not an instance of class Department.
>> If magic is so great, why don't you like for the framework to magically
>> transform the bytes from the DB into a Department?
>
>
> Not sure I understand. We can do this:
>
> Department = db.define_table('department',Field('name'))
> Teacher =
> db.define_table('teacher',Field('name'),Field('department',Departement))
> Teacher.insert(name="Max",department=Department.insert(name="CDM"))
>
> for teacher in db(Teacher).select():
> print teacher.name, teacher.department.name
>
> for department in db(Department).select():
> print department.name
> for teacher in department.teacher.select():
> print '-',teacher.name
>
> for row in db(Department.id==Teacher.department).select():
> print row.teacher.name, row.department.name
>
>
>>
>> - Allowing arbitrary python code on the template is a first step for
>> having templates filled with business logic especially when you work with
>> not-so-perfectionist programmers. Web templates are already a mess because
>> you can intermingle css+javascript+html. If the framework prevents another
>> language to that party, great! Even if it means having to type a few extra
>> chars in another file.
>
>
> We agree there should not be logic in templates but there are exceptions
> (for example generating HTML recursively). We allow those exceptions.
>
>>
>> - I agree that the magic regarding request execution is a matter of
>> preference more than a technical one.
>>
>>
>> - The editor is only useful if you're making your first steps in
>> programming. For all other professional programmers it has no value. Even if
>> it is a third party app, you still have to make sure that changes to web2py
>> don't break anything. I think it would be much more useful, for instance, to
>> build an orm on top of the dal.
>
>
> I agree about the editor. I use emacs. I still do not see what an ORM buys
> us that we do not already have. Can you provide an example.
For professional programmers, instead the editor, I'm developing rad2py ;-)
http://code.google.com/p/rad2py/
Also, please note that the relational model (and so the DAL) has a
"mathematical" formal theory behind (relational algebra and database
normalization) with a industry standard query language (ANSI SQL,
worldwide recognized as ISO/IEC 9075-1:2012):
http://en.wikipedia.org/wiki/Relational_model
http://en.wikipedia.org/wiki/Database_normalization
http://es.wikipedia.org/wiki/SQL
In fact, there are some relational databases like PostgreSQL that
implement some Object-Oriented capabilities, and there is some formal
research in "The third manifesto":
http://www.thethirdmanifesto.com/
AFAIK there is no formal theory for any ORM. At the first time, you
will notice some OOP benefits, but the hidden costs are:
* learning a non-standard query language (many times it is incomplete
and changes often, with )
* forcing you to use OOP techniques (that may not be viable for high
school students or casual programmers)
* sticking with a particular programming language and/or few database engines
* performance issues (for example, most times you don't need all the
fields of a table)
* lack of declarative expressiveness (many times you'll end writing
procedural code, fetching, mixing and processing records by hand...)
IMHO web2py DAL is a solution for almost all of this, allowing you to
write a web app without a deep experience in OOP, and in the end you
wouldn't need to write any SQL by hand, as most ORM needs when you
have to bypass their limitations.
Also, there are styling and readability issues, for example, look at
the Django ORM Tutorial example:
Poll.objects.filter(question__startswith='What')
In web2Py DAL it would use more standard python methods:
db( db.Poll.question.startswith("what") ).select()
Which one is more pythonic?
BTW, the ORM example get worse when you must get related fields, use
multiple conditions, etc..
There is a great website with a deep analysis on selected quotes about
this topics:
http://www.dbdebunk.com/index.html
Best regards,
Mariano Reingart
http://www.sistemasagiles.com.ar
http://reingart.blogspot.com
