> What do you miss, specifically, from the DAL standpoint ? >
Well, frankly, as I said - I LOVE THE DAL (!) :) I don't "miss" anything from it, in fact, I prefer it onto SQLA's SQL-Expression layer - as I said. But it's not the issue at hand. It's not what I am missing from the DAL. It's what I am missing from web2py. I don't or an ORM as somthing that the DAL is missing. I think of it as a bonus-layer on-top of it, that web2py is missing. The reason is that I don't expect the DAL to be something that it is not. As I said, I use the DAL extensively. I would continue to do so, even if/when web2py would have an ORM layer. I do not inend to use an ORM-layer for everything. That would be a poor design on my part. Here is a REALLY grate talk, describing the SHORTCOMINGS of some common-forms of ORM implementations: http://www.youtube.com/watch?v=E09qigk_hnY As you will see, the problems are not in the ORM concept as a "philosophy". The problems arise from inadequate "implementations" of ORMs, that "hide" and "abstact" TOO MUCH, and are not built in a layered-fashion, so do not provide the necessary flexibility to define schemas and other factors of the data-model "manually", override/define defaults for structural/behavioral patterns, as well as configuring save/load strategies. These are crucial characteristics of a "truly" useful ORM. AFAIK, SQLA might be the only one who does that right, all the way to the ORM level - at least in python-land. As for MY use-case, and hence my reason for wanting an ORM layer: I am architectonic a collaborative-system, that integrates financial-management, project-management, process-management and content-management - all under a single roof using a single database. It's an ambitious software-project, which was quite novel in it's scope when it first started. Why would I want an ORM? Well, it's not that I NEED it, it can very well stay ORM-less, however: Once we reaches a certain volume of code, and certain level of complexity of the data-model, it started to become very difficult to maintain and reason about. We have hundreds of tables and many thousands of lines of code, and it lacks structure to some degree. Yes, MVC does help - a lot - but it's not enough. The MVC part is actually pretty straight-forward. The problem is the spaghetti that emerged in our custom-models, that our controllers use. You might argue for poor-software-design on our part, but I believe it would be more than a little disingenuous to deny the implication of not having an ORM in the models... Additionally, there are performance issues that a well-designed ORM can solve - but that may have more to do with the implementation of Units-Of-Work in SQLA more than an ORM, however I still believe that using an ORM model, can help a lot in defining clusters of operations - that would then be ordered and aggregated into a transaction. It may provide orders-of-magnitude of better performance in some cases, and may be the only way out of the N+1 problem. For example, in one of the threads I read, Massimo gave an example of how an ORM can be emulated using the DAL. This example included a db-query inside a nested for-loop... Now, we recently did a massive profiling of our application, and guess where we found the bottlenecks... This leads me to the subject of hierarchies: Sometimes, there is no way to model a query that scans a tree of records, without resorting to this kind of awful approach... This is a real problem. Now, I am not sure whether SQLA can solve this, and if so how. But I have a feeling that using an ROM to model a record-tree, and using a transcriptional aggregating mechanism that introspect this ORM and infers a better aggregate for a transaction, might have huge performance benefits. I saw some examples in the long lecture from PyCon-2013, but I'm not sure it modeled a hierarchy... Anyways, I can elaborate more on my use-case if you think I should, but I think you get the idea... Basically we are talking about a tree of "production-items", that relate to a table of budget-items, but also that each node in the item-hierarchy has it's own tree of "tasks", and each task has it's own tree of "comments" for collaborative messaging. Additionally, each task may have a tree of file-records representing a CMS of versions of files that are used in the process of executing that task. then there's a status-matrix for representing task-status's pipeline-process... I really don't know how far I should get with this description, but you may get the point - it's a huge tree-of-trees... The most horrible data-model for a relational-database, and one that can benefit a lot from an ORM. I was thinking about moving that data into an ODB such as ZODB, but I still want the data to be stored in the same Postgres DB, in the back-end - so THERE I though I could use an ORM ontop of the DAL, as an adapter for a ZODB back-end... But that was a wild idea - I would much rather solve everything within web2py, and there also, an ORM could really help... -- --- 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.
