On 08/12/2011, at 9:26 AM, Ted Han wrote: > I've got a patch somewhere that allows one to patch in different types of > joins, but i never merged it in because it breaks the abstraction :\
I'd love to see what this looks like :) I don't think it should be a concern if it "breaks the abstraction", provided that it's documented that it is geared towards SQL data stores. I don't believe it's possible to have a perfect abstraction that prevents you from using SQL while still supporting all the features of SQL. I'm willing to wait and see how DM2 pans out, but there are just too many edge cases that I have this awkward feeling it will still be a closed box capable to leaving you in a place you don't want to be when it comes to complex queries, if it doesn't provide the means to work directly with SQL. We use DM's support for non-SQL data stores with a few different adapters (REST, memory) and I do think that is a big selling point to DM, but supporting other data stores should not mean not supporting SQL purely on the basis that it doesn't work with those other data stores. 95% of use cases will be with SQL databases, so focus on that 95% and provide a (large) subset to the rest. Allowing SQL injection goes a long way to solving this. Other examples where the lack of ability to use SQL becomes an issue are ordering by the result of a native RDBMS function, doing joins to derived tables (inline temporary views) and using native RDBMS functions in a join condition. These are all things anybody who's worked on a large website that requires a heuristic type of analysis on the data has probably done at some point or other. Just my $0.02. -- You received this message because you are subscribed to the Google Groups "DataMapper" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/datamapper?hl=en.
