Dan,
If a coder has reason to believe that saving a model will fail, then they
could use new() and then save(). Thus create() would be reserved for those
times when persistence failure is not part of the normal workflow.
In its current form, create() does not provide a meaningful shortcut over
new and then save, since the return value has to be manually checked. If
create() returned nil on failure, then subsequent calls that depend on the
return value would inevitably fail.
That is, this is good:
foo = Foo.new
if foo.save
...
else
end
And this is good:
bar.foo = Foo.create(...)
bar.do_something
But this is not good:
bar.foo = Foo.create()
if bar.foo.new_record?
...
else
...
end
..tony..
On Sat, Dec 13, 2008 at 12:52 PM, Dan Kubb (dkubb) <[email protected]>wrote:
>
> > The current situation is that the Model#create method "silently" fails
> > if the validations fail. That is, there is no exception, and the
> > return value is basically the same for success or failure; i.e. the
> > model instance. What this means is that code that uses the return
> > value is fooled into thinking the create() succeeded even though it
> > failed. This leads to hard to find bugs. I know this from experience :-
> > (
> >
> > The return value from the create can be checked to determine success
> > or failure, but this is a pain and easy to forget to do.
> >
> > So my suggestion is this: create() should return nil on failure. This
> > solves all the aforementioned problems, and seems like the obvious
> > solution. Am I missing something?
> >
> > I could not find a ticket filed for this. If I missed it, let me know.
> > Otherwise I will file one, possibly with the patch.
>
> While I can understand your reason for this, the problem I'd have is
> you'd have no way of finding out why the create failed. The reason we
> return the unsaved resource is because you can call
> Resource#new_record? on it to see if it was persisted or not, and if
> not you can introspect the resource to know the reasons why. This is
> the convention we've established with other persistence methods in
> DataMapper and it seems to be working quite well.
>
> Dan
> (dkubb)
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
