Marten Feldtmann wrote:
> Hmmm, what you want is not that easy. It means, that the object
> data is stored several times on the client:
>
> - you MUST hold an independent cache for each open connection
> to the database.
> - you MUST copy the values from the cache to the language
> dependent representation.
No it's stored once on the client. The language dependant cache IS
the cache.
> And you still do not get the result you want to have: the
> integrity problem. What happens, if the cache is not big
> enough. How are cached objects thrown away ? Garbage Collector
> in the cache system ??
The most simple scenario is that all objects are discarded upon
transaction
commit.
Beyond that, there are other scenarios. Like if you want to reclaim some
cache then UPDATE the database with any changes and leave the
transaction
open. If you need an object again then you read it in again.
But to a large extent, memory management is based on the model of
the programming language that you use, and managing it properly. Even
if you use JDBC you can't just slurp gigabytes into memory. You have
to re-use memory according to the conventions of the language in use.
> And another point: this has nothing to do with an ODMG interface.
> It's just a nice performance hint for database access, but
> ODMG has nothing to do with it.
What has nothing to do with ODMG?
> Normally the identity is assured by the language binding - either
> by the database (as you would like it) or by the binding of a
> particular language to this database.
>
> To get an ODMG language binding you may use the libpq. You may
> put a cache system on top of this libpq and you have the thing
> you perhaps want to have. That's all you really need.
Yes, but it's nice to compete on performance too. Whether libpq has
inefficiencies that prevent that is to be seen. Many commercial
ODBMSes are blindingly fast on object retrieval.
> What indeed would be a big win, it the chance to retrieve different
> result sets with one query !
I'm working on it.