Without addressing all of the issues I would like to make two comments:
1) In the past we have created ORM structure on top of DAL to allow use of
Django models and SQLAlchemy models with DAL. The code is here:
http://www.web2py.com/AlterEgo/default/show/189
Nobody paid attention.
2) I prefer the DAL syntax because I foten program in this way:
MODELS = [
('office', [
{'name': 'email_address', 'label': 'Office E-Mail Address'},
{'name': 'office_location', 'label': 'Office Location'},
{'name': 'office_phone', 'label': 'Office Phone'},
{'name': 'fax_number', 'label': 'Office Fax Number'}]),
)]
def autofield(f):
ftype = f.get('type','string')
requires=None
elif not requires and f.get('required'): requires = IS_NOT_EMPTY()
if ftype=='text': represent=lambda v,r=None:MARKMIN(v)
return Field(f['name'],ftype,requires=requires,
represent=represent,label=f['label'])
for tablename, fields in MODELS:
fields = [autofield(f) for f in fields]+[auth.signature]
db.define_table(tablename, *fields)
And allow customization of the code by editing the MODELS table instead of
changing the code. ORM make the code very inflexible in this respect. They
also are slower.
On Saturday, 27 April 2013 08:18:45 UTC-5, Arnon Marcus wrote:
>
> I am in the process of researching ways to improve the structure of my
> web2py-app's code, simplifying usage of certain areas, and enabling
> RPC-like interface for external programs.
>
> I use web2py for over 3 years now, and love every aspect of it -
> especially the DAL (!)
>
> However, as the code grew larger, and
> as hierarchical domain-model-patterns started to emerge, I started to look
> for alternative ways of accessing and using the portion of the data-model
> that is strictly hierarchical in nature.
>
> It is a huge controversial issue with relational-data-models which contain
> hierarchies. I don't intend to open a large discussion about this here.
> Suffice it to say, that even the most die-hard SQL lover, would admit
> it's shortcomings when hierarchies are introduces into the data-mode. It is
> an unsolved (probably "unsolvable") problem in data-model theory.
>
> So it is no a matter of looking fot the "best" solution, because there can
> not exist such a concept - even in theory.
>
> It is a matter of looking for the "most-fitting" set of trade-offs for the
> problem at hand.
>
> That said, some projects are large and/or varied enough, that they *DO
> *include
> both *highly-relational* areas*,* *as well as* *highly-hierarchical*
> areas *- within the same data-model (!)*
>
> For such use-cases, a more flexible/hybrid approach is beneficial.
> You don't expect to have to choose either/or relational-models
> vs. hierarchical-models - you expect your framework to include and
> facilitate support for both approaches for the same database.
> You would use the relational-features of the framework for when it is most
> suited for, and hierarchical-features for when IT makes better sense.
> Ideally, your framework would be built in an integrated-yet-layered
> design, that would make it easy for you to accomplish both approaches in
> a synergetic manner.
>
>
> My research has led me through ZODB and SQLAlchemy, just to get a feel for
> what an ORM could provide. Aside from reading a lot and watching a lot of
> lectures about these technologies, as well as general opinions about them,
> I have also taken the time to *really go through tons of threads in this
> group about these issues. as well as the web2py documentation.*
>
> Bottom-line, my current feelings about this issue, is that there is still
> something missing in web2py to facilitate the construction of higher-levels
> of abstractions, that are more focused on business-logic than
> database-schema. I also feel that there are "dogmatic" sentiments being
> thrown from both sides of the fence in this flame-fest fiasco.
> I think this hurts us - a lot.
>
> I think a more constructive approach would be to acknowledge that there
> are different use-cases that can benefit from different approaches, and
> that this leads to opposing opinions regarding certain trade-off that are
> being sought after.
>
> I think that web2py has taken an approach that is still too narrow-minded
> when it comes to supporting multiple-approaches, and that a layered-design
> could be beneficial here.
>
> Case in point, the philosophy and design of SQLAlchemy:
> http://www.youtube.com/watch?v=uvFBXxftvN4
>
> Now, just to be clear, I think that the web2py-DAL's API is much cleaner,
> simpler, and more easy and fun to use than SQA's API, at least for the
> SQL-Expression layer. But I also think that SQA's is a more flexible
> approach - it can target a more varied set of use-cases.
> Contrary to most of what I've read about SQA in this group, it's ORM is
> NOT mandatory, nor is it a "necessarily"
> more-restrictive/less-performant way of using the database. I think most
> criticisms I've seen here of it, are ill-informed, and have a somewhat
> "prima-facie" smell to them. They mainly attack the ORM concept in it's
> Active-Record form, which is NOT what SQA has. They also don't consider the
> layered-architecture of SQA, and compare the DAL with different
> implementations of ORMs that ARE more restrictive and obtuse, "assuming"
> that this is probably what SQA does, when in fact it is not. They compare
> the DAL to SQA's ORM, which is a fundamental mistake(!) The DAL is not
> comparable to SQA's ORM layer, but to it's SQL-Expression layer(!) These
> API's are almost identical in what they do - only the interface is
> different. So I could very well refer to SQA's SQL-Expression layer, as
> being SQA's DAL.
> SQA's ORM is something different, that to my knowledge, web2py is lacking.
> It is a layer "on-top" of it's DAL, while "using" it's DAL, as well as
> lower-layers, in an integrated fashion.
> In short, SQA is NOT a single-layer ORM (!)
>
> Now, what I think is missing, is something comparable to SQL's ORM in
> web2py - another layer on-top of it's DAL. Not a set of classes, but a
> single abstract-class meant to be inherited from. There are many operations
> that can be automated when constructing an ORM layer on-top of web2py's
> DAL, using the DAL's already-existing schema information. These could
> benefit the construction of ORM classes using the DAL.
> Examples for such benefits could be seen in the second part of this talk:
> http://www.youtube.com/watch?v=woKYyhLCcnU
> ** This is an almost 3-hour talk from PyCon 2013, covering most aspects
> of SQA that even the most experienced users of it might be unfamiliar with
> - it is fast-paced and highly condensed, and well-worth the time to sit
> through.*
>
> These automations, I predict, would emerge as recurring-patterns for
> people trying to implement such a thing in web2py, and what I am looking
> for, is an integration-abstract-layer with tools (in the form of
> abstract-methods) that would facilitate the design and implementation of
> ORM classes using the DAL.
>
> I don't have a clear conception of how such a thing would look like, I
> just have a general idea that such a thing would be most beneficial in many
> use-cases for which that DAL by itself is insufficient.
>
> I feel that the fear of having such a layer "restrict"
> future development by locking-down the business-data-model are unjustified.
> Refactoring can still occur later-on, and should occur with minimal effort
> by the developer using web2py - the framework should support and facilitate
> these kinds of refactoring scenarios, with appropriate auxiliary methods in
> the form of adapter/proxy design-patterns. If the ORM-abstract-class's
> design is built up-front using such patterns, than this would facilitate
> refactoring, and thus avoid scarring-off developers from using it.
> It should also facilitate performance-optimizations, by way of a
> transactionally-aggregating queries and updates/inserts automatically.
> Optionally, this abstract-class would be meant to be
> "multipally-inheritted-from", using the mix-in pattern. This way, a
> developer can have a separate class-hierarchic dealing with
> pure-business logic, to keep separation-of-concerns between database-usage
> and domain-logic, and also to enable re-use of code for other DAL's if
> needed (i.e, in a python-client that talks to web2py via rpc).
>
> These are all just ideas, and perhaps I am missing some things - maybe
> such capabilities already exist in some other form that I am unaware of.
> I would appreciate any references to such uses, if they already exist.
>
> (e.g - I am not too clear about lazy-tables and computed-fields, but I
> think they are an interesting start in this direction - I just haven't used
> them yet, as we are still using an older version of we2py that does not
> include them)
>
--
---
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/groups/opt_out.
