Re: [cx-oracle-users] Re: Need fetchall invalidate LOB locators?

[Anthony T. <ant...@gm...>]

On 7/15/05, Hamish Lawson <ham...@gm...> wrote:
> Anthony Tuininga wrote:
>=20
> > without looking at the code I would guess that [DCOracle2] define new
> > LOB locator variables for each of the rows that are fetched. That
> > seems to me to be a lot of overhead for very little gain -- unless you
> > can give me some valid reason for why fetchall() is a good idea when
> > dealing with LOBs.
>=20
> The main reason I'd offer is completeness and to avoid special-casing.
> I've been working on the contribution of an Oracle driver to the PyDO
> 2 ORM project, and I've been obliged to reimplement one of the
> inherited core methods just because it uses fetchall; I can envisage
> other situations where code that is not our own might expect to be
> able to call fetchall. You are right of course that there is a memory
> overhead in allocating LOB locator variables for each row. But any
> time the programmer chooses between fetchall and fetchone/iteration,
> they are deciding on a trade-off between memory and time costs. Why
> for the special case of the resultset's having LOBs should cx_Oracle
> remove that choice from the programmer?

The main reason is because I can't tell up front which method you are
going to use. Thus, I would have to use the "bad" method at all times.
If you can think of a sane way of getting around this problem I'd love
to hear about it. If any one else wants to chime in with an opinion
I'd love to hear those, too.

> Hamish Lawson
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&opclick
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>