ah, thanks for the DB synchronize tip,yes I want to keep db independent and indeed would have to do so myself since that's a requirement but if something is not in Sequel I now know that I can drop down to the adapter level and refer to that api.
as far as to what is a good name for that method I'll call it cursor_loop :) seriously good question , table.all_pages do ... end ? removing method caches doesn't sound good :) , silly question I'm guessing that's per Ruby process and not globally for the installed instance of Ruby , yeah silly question, can't be. wonder how Jruby manages that ? but I will at least isolate the use of extend to just that code that will rely on paginate extension. hold on, though, the code that you have provide below i.e. ea_paged does not rely on the pagination extension i.e. its using "limit" , another silly question but I have to get this all right , its an active project. thanks again, very helpful -Charles On Fri, Jan 25, 2013 at 11:37 AM, Jeremy Evans <[email protected]>wrote: > On Friday, January 25, 2013 6:53:47 AM UTC-8, Charles Monteiro wrote: >> >> Thanks again for your prompt attention. >> >> I'm porting stored procs i didnt code in the first place but my >> requirements are to keep everything in place , to create one code base that >> will work transparently across oracle and postgres drivers since we will be >> supporting the use of either db based on the client. >> >> Indeed so far my examination of the code reveals that rhe use of cursors >> is to buffer the result set and not a fetch, examine and possibly bail out. >> >> I can build the transparency myself , my outsranding issue is that I dont >> know if thru sequel I can engage the native oracle cursor. >> > Sequel does not have any support for native Oracle cursors. However, with > Sequel you can drop down to the driver level any time you want: > > DB.synchronize do |conn| > # conn here would be the JDBC connection object if you are using the > jdbc adapter > end > > So if there is a way to do what you want at the lower level, but Sequel > doesn't expose it directly, you can use synchronize to get directly to the > lower level. Of course, then you are in adapter/database dependent land, > and have to use the connection API that the driver exposes (not the > database-independent Sequel API). However, if you are planning on using > just the jdbc adapter, you shouldn't have that many portability issues, as > the drivers should all expose the JDBC API. You can still use other parts > of Sequel to generate the SQL that you can pass to the lower levels. > > Regarding paginate , I understand your concerns, however the specidic >> code that utilizes cursor support is used in an end of business day batch >> process where the db is locked out for any other update. >> >> Ill admit to being ignorant of the implications of "extends" >> > You shouldn't have any problems using the pagination extension then. The > issue with Object#extend is that it clears method caches on most ruby > implementations, but that really isn't an issue unless performance is > critical. > > My main objection to the pagination extension is that most of what > paginate does can be achieved with a simpler limit call. The returned > dataset supports a bunch of additional methods, but if you aren't using > them, there really isn't a need for the pagination extension. > > Now each_page is slightly different, but if you just want to process the > whole dataset without keeping all rows in memory, it could be implemented > in a more transparent way (yielding rows instead of datasets, transparently > handling multiple queries). Here's the general idea: > > class Sequel::Dataset > def each_paged(rows_per_fetch=1000) > offset = 0 > done = false > until done > done = true > limit(rows_per_fetch, offset).each do |row| > done = false > yield row > end > offset += rows_per_fetch > end > end > end > > I think it may be worth adding such a method to the core of Sequel, since > it is database-independent and generally useful. I'm not sure if > each_paged is a good method name for it, though. If anyone has a > suggestion for a better name, please speak up. > > > Thanks, > Jeremy > > -- > You received this message because you are subscribed to the Google Groups > "sequel-talk" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > Visit this group at http://groups.google.com/group/sequel-talk?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- Charles A. Monteiro www.monteirosfusion.com sent from the road -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sequel-talk?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
