[odb-users] query results not being cached?

Wed Jun 6 13:58:03 EDT 2012

Hi Boris,

My apologies; I see now (with some embarrassment) that this specific Oracle limitation is well documented.

Under many circumstances, our application expects to find exactly zero or one instance for many specific queries, but finding two or more would lead to an error scenario.  Application logic is the following in many such cases:

        if zero instances, create a new one

        if one instance, update the one found in the db

        if two or more, do nothing and return an error

Your alternative approach using the view works well for my needs, since I can determine the count and then perform the query if there is, indeed, only one instance.  I don't see a clean way to do the same by only iterating over the result, unless the iteration determines the count and temporarily holds a reference to the single instance (if there is only one).  I'll continue to try a few different approaches to see which one is most compatible with our current implementation.

Thanks again for your help!

Craig

-----Original Message-----

From: Boris Kolpackov [mailto:boris at codesynthesis.com]

Sent: Wednesday, June 06, 2012 12:15 AM

To: Burton, Craig

Cc: odb-users at codesynthesis.com

Subject: Re: [odb-users] query results not being cached?

Hi Craig,

Burton, Craig <crburton at tnsi.com> writes:

> I am not able to call "size()" on query results even if I try to use

> the "cache()" method on the results template.

For some databases (right now Oracle, SQLite, and MS SQL Server),

caching (and therefore size()) is not supported. This is documented

in the database-specific chapters. For Oracle that would be Section

16.5.2, "Query Result Caching":

http://www.codesynthesis.com/products/odb/doc/manual.xhtml#16.5.2

If you are interested, in the case or Oracle, supporting size() would

require switching the query result cursor to the scrollable mode. This

results in a much worse performance compared to the forward-only mode.

There is also a long and complicated list of limitations of scrollable

cursors that stipulate the kind of situations that are not supported

(specifically, support for BLOB/LONG types is very limited).

So it is better to try not to rely on knowing in advance the number

of entries in the result. Specifically, any optimizations that you

may want to make (e.g., reserve the space in the vector, etc), will

be inconsequential compared to the cost of supporting size(). If

you really need to know the size prior to the iteration, then the

best you can do is probably run a separate query that returns the

count, for example:

#pragma db view object(MyPersistentClass)

struct MyPersistentClassCount

{

  #pragma db column("count(*)")

  std::size_t count;

};

size_t count = ora_db->query<MyPersistentClassCount> (pred)->begin ()->count;

Boris

This e-mail message is for the sole use of the intended recipient(s)and may

contain confidential and privileged information of Transaction Network Services.

Any unauthorised review, use, disclosure or distribution is prohibited. If you

are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

[odb-users] query results not being cached?

[odb-users] query results not being cached?的更多相关文章

随机推荐

热门专题