On Oct 22, 10:56 pm, "Matt Aimonetti" <[EMAIL PROTECTED]> wrote: > hehe since my DM adapter was mentioned I guess I should give my opinion. > > I actually agree with Kyle and I would probably not use an adapter unless > Tokyo Cabinet can handle conditional statements. > > A good example would be couchDB. I don't think the adapter makes a lot of > sense. Don't get me wrong, it's great to have one and help people getting > started, but DM is very much RDBMS oriented, with a concept of clean/dirty > objects, collections, relationships. I feel, Couchrest (by Chris Anderson) > is a better fit since it's a lighter layer between your models and your > data.
I think DataMapper seems RDBMS oriented mostly because we were pragmatic about the design and decided to base some of the abstraction around something we understood well enough to be successful with. That's not to say we don't want to become more agnostic towards different storage engines though. In order for that to happen people need to start writing adapters that bend and stress DM's API. The adapter API is relatively stable right now, but that's not to say if a new abstraction can be found that better supports all the storage engines we won't consider it.. we just need real world cases to build on first. I'm beginning to see three separate use cases that DM can handle, but that not all underlying storage engines support: - Read/Write by Key - Read/Write by Search - Aggregate Reporting I should start by saying that "Aggregate Reporting" is something DM can handle with plugins like dm-aggregates, but there will never be native support for that built into dm-core. If you're doing alot of reporting or anything that requires the equivalent of GROUP BY, COUNT, SUM, AVG, etc and you're not using an RDBMS based adapter, then DM might not be your best option. However, the other two cases should be handled by DM pretty well. The main limitation is that some engines like Tokyo Cabinet can only lookup an object by it's key blazingly fast, but not perform searches. Then there are engines like Sphinx that can handle searches extremely well. The engines that can do both, like the RDBMS based ones, typically perform nowhere near the specialized engines. DM makes it possible to define a single model, but use different repositories and engines for different purposes. For example you could use one engine for key lookups, one for searching and one for aggregate reports. You could use hooks, message queues and/or background processes to keep the data in sync between the various engines. If you're at the level where you've outgrown generalized engines like the RDBMS ones, then its probably worth considering. Dan Kubb (dkubb) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "merb" 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/merb?hl=en -~----------~----~----~----~------~----~------~--~---
