Rails core - Apr 2009 - More specific subclasses for ActiveRecord::StatementInvalid

Raising ActiveRecord::StatementInvalid as the single exception for 
anything that might go wrong is rather unspecific. There are 
differences between exceptions, some signify plain programming errors, 
others are caused by potentially recoverable faults. Specifically among 
the later are violations of uniqueness constraints.

Differentiating among the original causes in application or plugin code 
is rather nasty and potentially brittle as most developers only care 
about one or two DBMS. I suggest to push this functionality into the 
connection adapters and have them at least handle uniqueness violations 
specially by raising RecordNotUnique, subclassed from StatementInvalid, 
with a suitable hint as to which constraint has been violated.

Are there any general concerns against adding this functionality? 
Otherwise, I''ll start work on a patch.

Michael

-- 
Michael Schuerig
mailto:michael@schuerig.de
http://www.schuerig.de/michael/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Man, I''d *love* that. Specially considering the possible race
conditions of validates_uniqueness_of.

On Fri, Apr 3, 2009 at 1:25 PM, Michael Schuerig <michael@schuerig.de>
wrote:
>
>
> Raising ActiveRecord::StatementInvalid as the single exception for
> anything that might go wrong is rather unspecific. There are
> differences between exceptions, some signify plain programming errors,
> others are caused by potentially recoverable faults. Specifically among
> the later are violations of uniqueness constraints.
>
> Differentiating among the original causes in application or plugin code
> is rather nasty and potentially brittle as most developers only care
> about one or two DBMS. I suggest to push this functionality into the
> connection adapters and have them at least handle uniqueness violations
> specially by raising RecordNotUnique, subclassed from StatementInvalid,
> with a suitable hint as to which constraint has been violated.
>
> Are there any general concerns against adding this functionality?
> Otherwise, I''ll start work on a patch.
>
> Michael
>
> --
> Michael Schuerig
> mailto:michael@schuerig.de
> http://www.schuerig.de/michael/
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

On Sat, Apr 4, 2009 at 6:25 AM, Michael Schuerig <michael@schuerig.de>
wrote:
>
>
> Raising ActiveRecord::StatementInvalid as the single exception for
> anything that might go wrong is rather unspecific. There are
> differences between exceptions, some signify plain programming errors,
> others are caused by potentially recoverable faults. Specifically among
> the later are violations of uniqueness constraints.
>
> Differentiating among the original causes in application or plugin code
> is rather nasty and potentially brittle as most developers only care
> about one or two DBMS. I suggest to push this functionality into the
> connection adapters and have them at least handle uniqueness violations
> specially by raising RecordNotUnique, subclassed from StatementInvalid,
> with a suitable hint as to which constraint has been violated.
>
> Are there any general concerns against adding this functionality?
> Otherwise, I''ll start work on a patch.
I''d love this, it''s one of the things I really liked about
spring from
my java days.  rescuing ForeignKeyContraintViolation or
DeadlockLoserException etc would be great.

http://static.springframework.org/spring/docs/1.2.x/api/org/springframework/dao/DataAccessException.html

Their approach is quite nice with a parallel set of classes for the translation:

public class MySQLErrorCodesTranslator extends
SQLErrorCodeSQLExceptionTranslator {
...

Definitely have a go and see what you can come up with.
> Michael
>
> --
> Michael Schuerig
> mailto:michael@schuerig.de
> http://www.schuerig.de/michael/
>
> >
>


-- 
Cheers

Koz

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

On Saturday 04 April 2009, Michael Koziarski wrote:
> On Sat, Apr 4, 2009 at 6:25 AM, Michael Schuerig
<michael@schuerig.de>
wrote:
[...]
> > Are there any general concerns against adding this functionality?
> > Otherwise, I''ll start work on a patch.
>
> I''d love this, it''s one of the things I really liked
about spring
> from my java days.  rescuing ForeignKeyContraintViolation or
> DeadlockLoserException etc would be great.
There you go

https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/2419

For the time being, only violated uniqueness constraints and invalid 
foreign keys are handled specially. I don''t know how to detect or 
test(!) things like DeadlockLoserException. Anyone, please fill in any 
blanks you perceive.

Michael

-- 
Michael Schuerig
mailto:michael@schuerig.de
http://www.schuerig.de/michael/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

On Sunday 05 April 2009, Michael Schuerig wrote:
> On Saturday 04 April 2009, Michael Koziarski wrote:
> > On Sat, Apr 4, 2009 at 6:25 AM, Michael Schuerig
> > <michael@schuerig.de>
>
> wrote:
> [...]
>
> > > Are there any general concerns against adding this functionality?
> > > Otherwise, I''ll start work on a patch.
> >
> > I''d love this, it''s one of the things I really liked
about spring
> > from my java days.  rescuing ForeignKeyContraintViolation or
> > DeadlockLoserException etc would be great.
>
> There you go
>
> 
https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/2419

Are there any further suggestions and opinions regarding this patch? For 
my purposes, it does all I need, right now. A major improvement would 
be enabled if the pg gem (PostgreSQL driver) passed on error codes -- 
is there any chance of this happening?

Michael

-- 
Michael Schuerig
mailto:michael@schuerig.de
http://www.schuerig.de/michael/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---