Kevin,
On Sun, Jul 18, 2010 at 07:50, Kevin inspir...@gmail.com wrote:
It'd be nice if http://datamapper.org/docs/associations included
mention of the name of the Resource table created, which keys/etc. Or
how to auto_migrate! it to get it created.. As is, its rather hard to
actually 'get
Ok, I've got Rails working with DM and I can display my pages, using
the tutes below:
http://code.google.com/p/appengine-jruby/wiki/RunningRails
http://gist.github.com/268192
However I appear to be using memory as store and I can't persist data.
I know I should use one of the dm-SQL-adapters,
Nice work :)
I should probably split it to a new topic, but about the belongs_to,
in my case sometimes users have an extra userdata table with a bunch
of optional things. So I want to basically do something
like :@user.udata.find_or_create (which is how it would work in AR),
but in DM it calls
Nice... Actually the default behaviour (not raising even though .save
failed) also made me think dm is broken. Anyways: It would be nice to
mention which class is thrown, i.e. SaveFailureError right? And that it has
an attribute @resource...
Regards, Philip
2010/7/17 Martin Gamsjaeger
I think the motivation behind DM not raising an exception on any save
failure by default is a very simple and intuitive one.
DM cannot assume to know exactly when a failing save can really be
considered *exceptional* behavior. Rather than forcing the user to
treat every single save failure as an
I see. Well I guess it depends very much on the project. In a rather complex
project I think exceptions should be preferred to prevent weird behaviour.
But in very small projects it might be more overhead than usage...
Still in my opinion a failing operation is exceptional but this is more of a
It probably is :) In any case, I updated the docs to mention the error
raised when #raise_on_save_failure is in effect and a save operation
failed:
http://datamapper.org/docs/create_and_destroy
Martin
On Sun, Jul 18, 2010 at 19:12, Philip Silva psilva...@googlemail.com wrote:
I see. Well I