FYI the AbstractAdapter API is getting a bit of an overhaul based on our usage patterns. It should be more consistent and easier for Adapter authors to write new adapters. Work is progressing on it now and it should be ready and tested within the next week or so. The reason I say this is if you decide to write such an adapter you’ll want to join us on IRC for the full details.

I’ve been using the following which almost helped:

module DataMapper::Resource::ClassMethods
def find_or_create search_opts, create_opts
create create_opts
end
def create create_opts
new create_opts
end
end

But at some point it fails in AbstractAdapter#read_set append to an association proxy.

Also many_to_many does not work.

Maybe its time to create a NullAdapter so people can write unit test and use models independently of a database? For example: serialize object graphs to a client that should not have access to a DB.

When is somebody going to create a truly orthogonal ORM for Ruby, without load-time dependencies, so we can stop modeling databases and start modeling objects with some possibility of reuse?

I’m so ready to ditch AR::Base for the right solution…

So the reason this is happening is because the NamingConventions are per-adapter. So one database can have one set of conventions, another can have a different set.

So, to inflect the #storage_name, we need a handle on the Adapter.

Obviously there’s nothing in the above code that actually needs the #storage_name at that point. So we just need to make it a little lazier, and you won’t have this issue. As you discovered, a valid connection isn’t necessary. Just a handle that responds to #storage_naming_convention and #field_naming_convention.

Thanks for the kind words.

On the plus-side, DM is unofficially-officially supported by my employer, Wieck Media, and I’ll be dedicating some more team hours to patching up some of the remaining issues. Expect a 0.9.2 release next Friday if not sooner.