Don't know why one does not use an oodbms. I've never used one. Are there
any serious alternatives to current rdbms?
Regarding the editor and editing in production. I was expecting that
argument and think that shouldn't be done unless its some extreme
emergency. One should not put code in production without testing it
thoroughly. What if your emergency edit in prod introduces a new bug that
causes a data loss for the client? Good practice says that you should have
at least 1 staging server to deploy stuff and test before prod.
Regards
On May 5, 2012 9:23 PM, "Michele Comitini" <michele.comit...@gmail.com>
wrote:
> I do not see nothing in web2py that stops a developer from using a
> third party ORM.
> Not a common pattern in web2py, because DAL functional approach gives
> addiction: you forget the COO (Class Object Oriented) and stick to the
> true semantic of python which is full OO. COO is typical of many
> static languages which need a static interface as blueprint for each
> object to be instantiated.
> The modeling using DAL is much relational modeling very little OO modeling.
>
> I agree it is more about faith and religion, but here a question
> raises. I suppose the answer is somewhere. I just did not find it
> yet.
> Let's suppose that OOP modeling were superior to relational, the
> question is why we keep using RDBMS's? There are some serious
> OODBMS's out there, why use an ORM then?
>
>
> mic
>
> 2012/5/5 Massimo Di Pierro <massimo.dipie...@gmail.com>:
> >
> >
> > On Saturday, 5 May 2012 11:51:22 UTC-5, Tiago Almeida wrote:
> >>
> >> Thanks for the comment. This is an interesting debate.
> >>
> >> Sábado, 5 de Maio de 2012 17:13:07 UTC+1, Massimo Di Pierro escreveu:
> >>>
> >>> On Saturday, 5 May 2012 10:23:34 UTC-5, Tiago Almeida wrote:
> >>>>
> >>>> 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.
> >>>
> >>>
> >>> this is somewhat a religious matter. We do not like to pollute the
> >>> namespace with one class per table. We do not even usually do
> Department =
> >>> db.define_table(...). We just expose db and access department via
> >>> db.department. Given this preference:
> >>>
> >>> db.departement.historical_assignments = Field.Lazy(lambda departement,
> >>> date: db(db.teacher.departement)(db.teacher.asdate<date).select())
> >>>
> >>> seems simpler and clear than to define a class and a method. It does
> not
> >>> pollute the namespace. In fact web2py does allow to create a
> VirtualField
> >>> class and map that into table, so that records have fields
> corresponding to
> >>> methods. We consider it a legacy feature because users prefer the new
> >>> syntax.
> >>> Yet this is kind of a religious issue.
> >>
> >>
> >> It may be a religious issue. I was assuming I already had the class
> >> defined because it made sense if this hypothetical app had a very
> complex
> >> domain layer. Like a very complex MMO game. I really believe that not
> all
> >> operations could be patched as virtual fields. What about operations
> that
> >> have a side effect, instead of returning something?
> >
> >
> > Perhaps the name virtual fields is not the most descriptive. A virtual
> > fields is very much like a method in an ORM. You can pass values to it.
> They
> > can do everything method can including "side effects" such as writing to
> the
> > db.
> >
> > db.teacher.give_raise=lambda row,raise:
> > row.update_record(salary=row.salary+raise)
> > and you can do:
> > for teacher in db(db.teacher).select(): teacher.give_raise(5000)
> >
> > Virtual fields can also store a state in the row very much like a method
> > stores member variables, access and change existing ones.
> > By doing this outside of a class the DAL make it easier to have virtual
> > fields which are context dependent. For example methods defined only for
> > users who have permissions, such as:
> >
> > if auth.has_permission('give_raise','teacher'):
> > db.teacher.give_raise=lambda row,raise:
> > row.update_record(salary=row.salary+raise)
> >
> >
> >>>>
> >>>> 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).
> >>>
> >>>
> >>> We do not want to "forget" that we have a DB system. One can only
> forget
> >>> when one builds simple queries. Ifone can only do simple queries than
> one
> >>> starts to think a relational database is not good enough. We want to
> make
> >>> sure .select() maps in an SQL SELECT, .insert() into SQL INSERT, etc.
> We do
> >>> not want to hide database access which can cause performance issues.
> This is
> >>> a significative difference. We do no need .save() and .get() because
> they
> >>> are kind of like .insert() and .select() but the mapping is not always
> as
> >>> clear. Moreover is not very Object Oriented either.
> >>
> >> Ok. This is the old issue of performance vs elegance and the correct
> >> answer really depends on the type of project. When you use Python, you
> >> "forget" that below you there is probably a cpu with lots of unused
> vector
> >> specialized instructions. They could be exposed, but they were not.
> >>
> >>
> >>>>
> >>>> 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.
> >>>
> >>>
> >>> This is what we do not like. The goal of the DAL is to try avoid this
> as
> >>> much as possible, although it does not prevent it.
> >>
> >> Again, it's a matter of project target.
> >>
> >>>
> >>>
> >>>>
> >>>>>
> >>>>> 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.
> >>>
> >>>
> >>> I see this in a different light. Web2py supported left joins,
> aggregates,
> >>> and nested selects 2 years before Django did. While they added those
> >>> features over time, we added so many other features (list types,
> native GAE
> >>> support, geospatial APIs for postgres, mongodb support, teradata
> support,
> >>> imap-dal support, expressions, lazy virtual fields, full auditing in
> all
> >>> database tables, multiple database support, semi-natural-language query
> >>> parsing, etc.) that it is pointless to even compare them today, and we
> >>> managed to remain backward compatible.
> >>
> >>
> >> This post is more of a debate about the usefulness of an orm in general
> >> than the state of django's orm vs web2py's dal. I've presented my
> arguments
> >> for prefering an orm in general, while supporting that for some
> specialized
> >> projects you should not use an orm. Regarding the feature set of
> django, I
> >> can say that Django suffers from a problem of too much inertia when it
> comes
> >> to change. It may be a consequence of having 3 or 4BFDL's instead of 1
> and a
> >> much larger community. There are huge, years long discussions about how
> this
> >> or that should be done, without conclusions. Also, I won't compare those
> >> features one by one because I'm not *that* informed about what django
> >> supports or not.
> >
> >
> > True. Elephants are slower then mice. :-)
> >
> >>>
> >>> The DAL expressions are consistently shorter then the equivalent Django
> >>> and SQLAlchemy ones (some example here
> >>> http://www.web2py.com/AlterEgo/default/show/150 and I would love to
> see a
> >>> counter example) and support more features than Django does (in the
> sense we
> >>> can use the DAL to generate more SQL statements than the Django ORM
> can).
> >>>
> >>> Web2py falls short of SQLAlchemy for support of legacy tables with
> >>> arbitrary primary keys (but we have been getting better) and for lack
> of the
> >>> concept of DB session (because we never needed that).
> >>>
> >>> Just for fun two years ago, I implemented a Django-compatible ORM for
> >>> web2py:
> >>> http://www.web2py.com/AlterEgo/default/show/189
> >>> Nobody used it so it died but it would be trivial to improve it to add
> a
> >>> mapping between arbitrary methods and virtual fields.
> >>>
> >>> Since you are building your own ORM, instead of starting from scratch,
> >>> you may want to look into proving that and still take advantage of the
> DAL
> >>> goodies underneath.
> >>
> >>
> >> I'm not building an orm :) It would be a fun exercise though.
> >>
> >>>
> >>> Anyway, please understand we value your comments as we can learn from
> >>> them.
> >>>
> >>> Massimo
> >>
> >>
> >> As I value this community comments'.
> >>
>
