On Tue, Dec 30, 2008 at 8:22 AM, Dan Kubb (dkubb) <[email protected]> wrote: > > Actually, this is ugly on purpose because we want to discourage direct > SQL usage from within DM.
Heh. I actually quite like that idea of making a certain call ugly to discourage it's use! > DM is an ORM designed to fetch and store objects in a data store > through a simple CRUD layer. It won't handle reporting very well, > since there's no way to simply construct a non-trivial query for > aggregate reporting in a way that will work with more than a handful > of storage backends. Even describing non-trivial aggregate report > queries between RDBMS' is a bit painful, but it gets insane when you > throw in CouchDB or web APIs. <snip other relevant stuff> This is, however, an intractable problem, since for anything more than trivial problems there is no "perfect" solution, simply best tools, and this means making sacrifices. In my current project the vast majority of DB access is blindingly simple, the sort of problem that scaffolding can actually solve (at least for the moment). I do, however, have a few queries that need in DB reporting - I need to iterate over a set of objects, joining on to a table and retrieving a count for joined objects for each row in the first set. (actually, this is a simplification) For now I have actually implemented this in an n+1 query style, with a ruby loop. Unpleasant and unscalable, but works for me right now. I like the idea of DM interfacing to Sequel. Pure Sequel is overkill for this project, but I might look into this further... Thanks Emma --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
