The really great thing about free open source software is that you can fork or write a wrapper for any module.
You don't even have to wait for someone else to agree that your idea is worth spending time on. On Saturday, April 27, 2013 9:18:45 AM UTC-4, 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.
