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 <mailto: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:
defget_review_average(row):
# all the code...
# ...
returnvalue
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))
defget_place_reviews_average(row):
# all the code calling review.value
# ...
returnvalue
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:
classReview:
author = Field()
value = Field('int')
valuea = Field('int')
valueb = Field('int')
place = Field('reference place')
defget_average(row):
# all the code...
# ...
returnvalue
classPlace:
name = Field()
description = Field()
defget_place_reviews_average(row):
# all the code
# ...
returnvalue
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:
classOtherReview(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
<mailto: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
<mailto: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
<mailto:web2py+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
