[odb-users] Sessions are not useful for application-wide purposes

[Rene Jensen]

Hi Boris.

Here is another post highlighting a problem that application designers
have. I am not even sure that you want ODB to server a purpose matching
what I describe. On with it...

A typical GUI program will usually make a distinction between models and
views.
Obviously model classes will relate to ODB in some way. Specifically:

- Model classes are kept alive for very long time, some as long as the
application lives
- They will integrate different aspects depending on which third party
libraries are involved. I my case they derive from QObject and uses Qt's
meta property system.
- They carry identity. No two objects with the same identify should exist
in the memory of the program at any time
- They should be resource managed: Certainly the entire database cannot fit
into memory at once

Views (for me those are Qt forms) are responsible for holding one or more
model classes alive. Views can stay alive for a short or long period
depending on the user.

Such demands doesn't rhyme well with ODB's concept of sessions. Again, the
problems sessions solve are:
1) They provide a way to ensure the same entity is not loaded twice.
2) They keep objects cached in memory.

The latter presents a problem: The obvious way to control uniqueness of
classes in memory would be to use an application-wide session. But that
would keep all touched objects alive forever.

FIRST SOLUTION:
Invent a "weak session cache", i.e. one that consists of weak pointers
(raising issues of atomicity of checks etc... but usually GUI programs has
just one GUI thread and a bunch of isolated workers). With such a session,
you could achieve (1) but leave it to the model AND view classes to handle
(2).

SECOND SOLUTION:
Let ODB use external factories for creating objects. Those factories could
communicate with an application-wide pool of weak pointers that was under
user control

THIRD SOLUTION:
Use inner structs for database data and only store pointers to those in the
model classes. That way the application code can keep its own tables for
converting those proxy-objects to real model classes when needed.
This is the solution I was forced to go with. I don't like it because there
is a huge maintenance burden and only a small gain in freedom.

What do you think?

Best regards,
Rene