Hello,
About webpy example, I think this is readilly possible in web2py, I mean it
just maybe a better way to structure your model declaration/defintion...
Did you try it with web2py?
Richard
On Mon, Nov 2, 2015 at 9:51 AM, Carlos Cesar Caballero Díaz <
desarro...@spicm.cfg.sld.cu> 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 web2py+unsubscr...@googlegroups.com.
> 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 web2py+unsubscr...@googlegroups.com.
> 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 web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
