That would be a cool feature..1 click deployment of code pulled from a
repository.
Regards
On May 5, 2012 11:19 PM, "Massimo Di Pierro" <massimo.dipie...@gmail.com>
wrote:
> I think we all agree that the built in editor if definitively useful. It
> does not substitute a normal editor for production quality development, but
> there are many occasions when it is useful: quick and dirty fixes, editing
> code when there is no ssh access, editing configuration options, etc.
> Anyway, the online editor is just one of the tools in the web2py
> administrative interface, including mercurial integration, error browser,
> web based shell. We are looking into integrating automatic pulls from
> github (and other repositories).
>
> Massimo
>
> On Saturday, 5 May 2012 16:30:33 UTC-5, Khalil KHAMLICHI wrote:
>>
>> I must agree to good practices but that does not mean I cannot deploy
>> tested code using the built-in editor.
>>
>>
>> On Sat, May 5, 2012 at 8:49 PM, Tiago Almeida
>> <tiago.b.alme...@gmail.com>wrote:
>>
>>> 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<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<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'.
>>>> >>
>>>>
>>>
>>
