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.
--
Este mensaje le ha llegado mediante el servicio de correo electronico que
ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema
Nacional de Salud. La persona que envia este correo asume el compromiso de usar
el servicio a tales fines y cumplir con las regulaciones establecidas
Infomed: http://www.sld.cu/
--
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.
