|
> The problem you've described is far from a new problem - it's the same problem space that is covered by ORMs. This is digression. I have in mind something I wrote, the most complex piece of code I've written in the past couple of years. It isn't actually well covered by ORMs. ORMs are usually tuned for (a) static schemas, and (b) graph navigation in OO-style. Give them a problem like "here's a filter in the form of a syntax tree, please give me the top 100 results from this 10 million line table" - where the table schema is determined at runtime - well, most ORMs can't even answer this question because schemas are assumed to be static. And if you want to control the join order using nested subtable joins, with predicates that don't need joins pulled out of the filter expression and pushed down, because MySQL's optimizer observably doesn't reliably do the right thing, ORMs don't give you that control. It wasn't an ORM kind of problem; think more something like a read-only Excel spreadsheet, but with typed columns, and a rich autofilter, on the web, scaling to millions of rows. The output of the database query is a page of tuples, not objects in any behavioural sense. In some ways a database seems like the wrong solution, but morphologically it's exactly right: the user data is rectangular, relational, has foreign keys to other tables, and needs to be sorted, filtered and joined with other user-defined schemas. Modelling the user schema as database columns performs better than any other database solution, and database solutions are preferred because shared state, transactions, etc. Because the product is closer to being an actual database than a program using a database, ORMs aren't tuned for it. |
Your rather unique use case certainly falls outside of the remit of what ORMs provide (cutting down on generic SQL boilerplate) but I'm unconvinced that what you built is in need of especially powerful language features to build it.