Hi, The issue about dal/orm, like Anthony said, there are tradeoffs to consider. In my opinion you loose too much not having an orm to gain very little with the dal. Let me continue my example. In the Deparment/Teacher hypothetical model, you also have assignment of Teachers to Departments. This assignment is very simple (for the sake of brevity) and has the start/end dates of the assignment and the function (just a string) of the Teacher in that Department. You now want, Given the ID of a department list all the assignments of all teachers along with their functions in a cool graphical timeline fashion. It's not about how you get the data. It's about the effort you have implementing this req. and how you organize your code. Do you? a) write your .selects() in the view function b) write a historical_assignments(dep_id) function somewhere that hides the DAL and call it from the view c) write a computed field on the department model d) write a method historical_assignments() on the class Department
To me, the d) option is by far the most elegant. I would have had the Department class created anyway, so it's a matter of sticking a method in there. If I am working with an ORM, by defining the classes, I automagically get the tables defined. Without it, I have to repeat myself, redefining the fields and the fields in the tables and their types, etc. etc. in the persistance layer. What if I didn't define those classes? Then I couldn't contain these kinds of business related operations into a single application layer and they would leak everywhere, for instance in to the views, being much harder to maintain. Regarding the higher vs different abstraction. A "perfect" persistence layer (if there is such a thing) allows one to actually forget that you have a DB system. I honestly don't care, from the biz point of view, if things are stored in tables in a DB, xml files or sent via the wire to China. I only care that I create my Departments, .save() them and get them later as they were saved .get(id=dep_id). Do you lose anything with this abstraction? Yes, of course. If you hide that it's a DB you lose, for instance, DB triggers. It's the normal tradeoff in any abstraction. If you use TCP, you get delivery guarantees and peace of mind regarding all the dropped/corrupted packets nonsense while loosing, say, realtime guarantees. Should we stop using TCP because we loose this 'realtimeness'? Of course not. Are there things that you can do with an orm that you can not with adal? No, it's quite the opposite. The dal exposes more details therefore allows you to do more. However, by exposing all these details, you get a tool that is harder to use (in the sense that you have to repeat yourself) for all the other scenarios where you don't need such details. Python is used because no one wants to deal with the nonsense of lower level languanges that arise from exposing too many details (manual memory management, target machine dependency, etc....). Lastly, If I am working with an orm and need to implement a really complex query, nothing stops me from going deeper and use the dal or even writing SQL. The same way, not all projects are done in Python. For professional programmers, instead the editor, I'm developing rad2py ;-) > > http://code.google.com/p/rad2py/ > Looks great. But I am still not convinced I would use it :P Also, please note that the relational model (and so the DAL) has a > "mathematical" formal theory behind I've learned this in college. I've never seen anyone use relational algebra in a real world project. I've also learned in my experience that database normalization sometimes has to go in order to get, for instance, performance. Don't really see how this scores points for the DAL. > * learning a non-standard query language (many times it is incomplete > and changes often, with ) > Don't see why it should change often * forcing you to use OOP techniques (that may not be viable for high > school students or casual programmers) > Like I said in my first post in the other thread and dragged out of context to here: Web2py is good as a learning tool. It also happens that I'm not a casual programmer so don't see that as an advantage. * 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) > An ORM does not have to select * everytime. > * lack of declarative expressiveness (many times you'll end writing > procedural code, fetching, mixing and processing records by hand...) > You also have to map data from the dal into you business layer by hand. > > > 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() > I've never said that Django's orm is perfect. That "__operator" thing could be done in a different way. Anyway I accept that minor annoyance because it saves me time overall. Gour quote: > It shows that it's not (always) wise to just follow whatever buzzword > the industry spits out in the attempt to bring sheeps to their flock. > If I was basing my technical decisions on buzzwords, I would be making a case for PHP running in the cloud, as a service :) Best regards, Sexta-feira, 4 de Maio de 2012 20:18:02 UTC+1, Mariano Reingart escreveu: > > On Fri, May 4, 2012 at 12:41 AM, Massimo Di Pierro > <[email protected]> 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 >
