Dave Rolsky writes: > The Pet Shop has a grand total of 13 tables. > > How well does this approach work with 90 tables?
Works fine with bivio.com, which has 50 tables. > How does it handle arbitrary queries that may join 1-6 tables, > with conditionals and sorting of arbitrary complexity? The ListModel can override or augment its query. You can load a ListModel from an arbitrary data source as a result. After the load, it can fix up rows, e.g. computing "percent portfolio" is not done in SQL but in Perl in internal_post_load_row(). The "automatic" sorting is handy for simple joins. For complex queries, there's no fully automatic solution for sorting. Here's a simple query: http://petshop.bivio.biz/pub/products?p=DOGS The ListModel declares which columns are sortable: order_by => [ 'Product.name', 'Product.product_id', ], The view doesn't need to say anything, because the Table widget queries the ListModel meta-data. The SQL query is dynamically constructed by the "o" HTTP query value. For complex queries, you may be able to take advantage of the sort infrastructure. There are no guarantees, but you have the rope. The software is designed for the 80% solution. As we see patterns develop in our code, we add general cases to the infrastructure. > I'm not a big fan of O/R. I prefer R/O. But to each their own. I guess we do R/O in the sense that we design the database relationally and then map PropertyModels one-to-one with the tables. Is that what you mean by R/O? Rob
