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.
