Anthony Eden
2007-Jan-18 00:43 UTC
Defining the expected behavior of DatabaseStatements.execute()
It would be very helpful if the core team could define and document the expected behavior of DatabaseStatements.execute(). The implementations appear to vary. Most adapters will return some sort of native result set, SQL Server returns nil and expects a block, DB2 and Sybase return the affected row count. So please, will someone in core explain the expected behavior and can the execute() documentation in the DatabaseStatements module be updated to reflect the required behavior. Thanks. V/r Anthony Eden -- Cell: 808 782-5046 Current Location: Melbourne, FL --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Michael Koziarski
2007-Jan-18 21:06 UTC
Re: Defining the expected behavior of DatabaseStatements.execute()
> It would be very helpful if the core team could define and document > the expected behavior of DatabaseStatements.execute(). The > implementations appear to vary. Most adapters will return some sort of > native result set, SQL Server returns nil and expects a block, DB2 and > Sybase return the affected row count. > > So please, will someone in core explain the expected behavior and can > the execute() documentation in the DatabaseStatements module be > updated to reflect the required behavior. Thanks.My understanding is that the return value of execute is undefined, but that it shouldn''t require a block. The use case is essentially: "Run this statement, I don''t need a return value" -- 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 -~----------~----~----~----~------~----~------~--~---
Tom Ward
2007-Jan-19 12:14 UTC
Re: Defining the expected behavior of DatabaseStatements.execute()
On 18/01/07, Michael Koziarski <michael@koziarski.com> wrote:> > > It would be very helpful if the core team could define and document > > the expected behavior of DatabaseStatements.execute(). The > > implementations appear to vary. Most adapters will return some sort of > > native result set, SQL Server returns nil and expects a block, DB2 and > > Sybase return the affected row count. > > > > So please, will someone in core explain the expected behavior and can > > the execute() documentation in the DatabaseStatements module be > > updated to reflect the required behavior. Thanks. > > My understanding is that the return value of execute is undefined, but > that it shouldn''t require a block. The use case is essentially: > > "Run this statement, I don''t need a return value"I agree, the behaviour of execute is undefined, beyond ''do this on the database''. select_one, select_all, select_value, insert, update and delete provide a standard interface to the db across adapters, while execute gives much lower level access to the underlying connection. So in general, you''re much better off using the former rather than the latter. BTW, while the SQLServerAdapter.execute can take a block, it shouldn''t require one. The block is used to give access to the result set from the database, without returning it (and running the risk that it isn''t closed after use). If no block is provided, the command should run with no return value. Tom --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Tom Ward
2007-Jan-19 12:28 UTC
Re: Defining the expected behavior of DatabaseStatements.execute()
On 19/01/07, Tom Ward <tom@popdog.net> wrote:> On 18/01/07, Michael Koziarski <michael@koziarski.com> wrote: > > > > > It would be very helpful if the core team could define and document > > > the expected behavior of DatabaseStatements.execute(). The > > > implementations appear to vary. Most adapters will return some sort of > > > native result set, SQL Server returns nil and expects a block, DB2 and > > > Sybase return the affected row count. > > > > > > So please, will someone in core explain the expected behavior and can > > > the execute() documentation in the DatabaseStatements module be > > > updated to reflect the required behavior. Thanks. > > > > My understanding is that the return value of execute is undefined, but > > that it shouldn''t require a block. The use case is essentially: > > > > "Run this statement, I don''t need a return value" > > I agree, the behaviour of execute is undefined, beyond ''do this on the > database''. select_one, select_all, select_value, insert, update and > delete provide a standard interface to the db across adapters, while > execute gives much lower level access to the underlying connection. > So in general, you''re much better off using the former rather than the > latter. > > BTW, while the SQLServerAdapter.execute can take a block, it shouldn''t > require one. The block is used to give access to the result set from > the database, without returning it (and running the risk that it isn''t > closed after use). If no block is provided, the command should run > with no return value.One more thing - now that 1.2 is out the door, surely now is a good time to rationalize ActiveRecord and the various adapters. To start the debate rolling, I''d like to say add_limit_offset! smells really bad. Surely there''s a cleaner way to manipulate the SQL than bouncing it between ActiveRecord::Base and the adapter? Thoughts? Tom --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Michael Koziarski
2007-Jan-21 22:59 UTC
Re: Defining the expected behavior of DatabaseStatements.execute()
> One more thing - now that 1.2 is out the door, surely now is a good > time to rationalize ActiveRecord and the various adapters. To start > the debate rolling, I''d like to say add_limit_offset! smells really > bad. Surely there''s a cleaner way to manipulate the SQL than bouncing > it between ActiveRecord::Base and the adapter?It definitely would be nice to refactor all the SQL generation out of Base and into the adapters, where they can safely override whatever behaviour they need to. I don''t know that there''s necessarily going to be any debate over that :). By all means, start another thread with what you have in mind :) -- 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 -~----------~----~----~----~------~----~------~--~---