Something like this was already implemented 4 years ago when we write a compatibility layer between Django and web2py:
http://web2py.com/AlterEgo/default/download/document.file.08621820-64d8-4db5-a85c-569a647a4437.py Perhaps you can take some of that code and re-adapt it. On Monday, 2 November 2015 08:50:34 UTC-6, Carlos Cesar Caballero wrote: > > The dal is a very good piece of software, and it can done practically > everything that any orm can do, but in my opinion, the problem is not what > we can do, but how we do it, for example, we have places, and the places > have reviews, it will be something like this: > > db.define_table('review', Field('author'), Field('valuea', 'int'), > Field('valueb', 'int'), Field('valuec', 'int'), Field('place','reference > place')) > > db.define_table('place', Field('name'), Field('description')) > > It's clean, there is no problem, but now we need to get the average on a > review values, and the average of all places reviews, the we get something > like this: > > def get_review_average(row): > # all the code... # ... return value > > db.define_table('review', Field('author'), Field('valuea', 'int'), > Field('valueb', 'int'), Field('valuec', 'int'), Field('place','reference > place')) > Field.Virtual('value', get_review_average)) > def get_place_reviews_average(row): > # all the code calling review.value # ... return value > > db.define_table('place', Field('name'), Field('description'), > Field.Virtual('value', get_place_reviews_average)) > > ok, now is not so clean, the "functions" are before the "variables" > declarations, we could add some validations, and we get functions code, > fields declarations, and validation code, in that order, when the model > grows, the code becomes more difficult to maintain, hardly if the person is > not who wrote the code. > Now let's see some weppy-like syntax: > > class Review: > author = Field() > value = Field('int') > valuea = Field('int') > valueb = Field('int') > place = Field('reference place') > > def get_average(row): > # all the code... # ... return value > class Place: > name = Field() > description = Field() > > def get_place_reviews_average(row): > # all the code # ... return value > > db.define_models(Review, Place) > > Now the code has a more natural structure, first variables and later > functions, we dont care the order, because at the end we declare it using > the define_models() function, and we can use inheritance simply like this: > > class OtherReview(Review): > valuebc = Field('int') > > Now the code is easier to maintain, and easier to reuse, we only need to > copy class files, and extend from them. > > This is not an orm, is just current pyDAL with an alternative structure > for table declarations. > > About the objects, if we could have real orm functionality, we could do > things like: > > object = db.mytable[id]object.name = "the name"object.save() > > or > > db.mytable.save(object) > > The non persistent variables is other thing, in some cases we need to use > non persistent variables, like flags, with the virtual or method fields, we > can define non persistent values, but we can't edit them. > > Greetings. > > > El 30/10/15 a las 15:34, Anthony escribió: > > On Friday, October 30, 2015 at 3:10:29 PM UTC-4, Carlos Cesar Caballero > wrote: >> >> We could use object oriented modeling, >> > > Yes, but the question is, what exactly does that mean to you, and how > would it improve things over the current DAL? Can you share a specific > example, possibly including pseudo-code? > > Also, are you saying you want an ORM, or are you using "object oriented" > more generically. If the latter, of course the DAL is already "object > oriented" in that most of the API involves instantiating objects and > calling methods on them. > > >> we could save our objects directly to the database >> > > What do you mean by "objects" here? Are you saying you want to save native > Python objects to the database? If so, that would be a feature of the > database rather than the abstraction layer interacting with it. Of course, > web2py does allow you to store arbitrary objects to any database if they > can be pickled or otherwise serialized and deserialized. Can you give an > example, and maybe point to how some other favored abstraction layer > handles it (e.g., SQLAlchemy)? > > >> , we could declare non persistent variables in objects >> > > Not sure what you mean by this. Is this something that can be handled via > virtual fields or method fields? > > >> , we could have a better code structure in our apps, we could maintain >> large models easily >> > > Can you be more specific? In web2py, nothing stops you from breaking up > model code into multiple modules. > > >> , we could reuse or extend model classes easily >> > > This would be one benefit of an ORM approach, though you can already use > table > inheritance > <http://web2py.com/books/default/chapter/29/06/the-database-abstraction-layer#Table-inheritance> > > with the DAL, and there are other methods of re-using code (e.g., table > methods). > > >> , we don't will need to worry about the class models files order >> > > That has nothing to do with the DAL or "object oriented" programming -- > that is related to the way web2py executes model files prior to the > controller and would affect any type of data model definitions. If you > don't want to worry about that, you can move table definitions to modules > or use models sub-folders along with response.models_to_run. > > >> , we could even load only the models that we need in controllers without >> write modules... >> > > How so? If using classes, the class declarations would still be executed > if they were in a model file. Do you think this would be much more > efficient than DAL lazy table declarations? > > Object oriented programming is not just use an object oriented programming >> language, and sadly, with web2py is difficult follow the object oriented >> paradigm when we develop applications > > > Are you speaking generally, or just with regard to the DAL? Is it really > that you want an ORM and to define database models as classes? If so, > again, it would be helpful to understand specific examples of where you > find that superior in some way to the DAL. > > Anthony > -- > Resources: > - http://web2py.com > - http://web2py.com/book (Documentation) > - http://github.com/web2py/web2py (Source code) > - https://code.google.com/p/web2py/issues/list (Report Issues) > --- > You received this message because you are subscribed to the Google Groups > "web2py-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > > > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
