> Perhaps some unification between these two - so that applications can be > portable accross both types - will emerge, and this would be useful. > > But I think the first step is to cleanly, intentionally separate the two > kinds of back ends and see where that leads.
These two statements are key. 1. A separate DAL for GAE/BigTable is needed to harness it. web2py is too relational specific and not portable to column oriented databases like BigTable. After going through several data model design iterations and getting to one that feels correct, web2py imposes the relational model on a non-relational model, which suggests to me the "portability" web2py provides to BigTable is in most cases, a good data model on the wrong data store or vice versa. web2py removes BigTable's benefit with the current DAL. 2. Patterns will emerge. When another is access layer is created for a like persistence layer, we should start seeing patterns bubble up and perhaps then, web2py will become a truer portable architecture. Meanwhile, a separate DAL feels more correct to me. True portability between each isn't known or clear; the architecture are not the same and should not be treated as such. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
