Bug 63713

I've tested this behaviour under Windows with JRE 1.6 and JRE 1.7
and Linux with OpenJDK 1.6 and 1.7

used JDBC-Drivers:

ojdbc6.jar
ojdbc14.jar

it seems,
Libreoffice reads all metadata for all found DB-Objects.
Maybe there could be a feature that limits this function only to those objects that are listet in tables filter.

Which LO version do you use? FYI, last one is 4.0.2 and 4.0.3 is gonna be released in a few days (see https://wiki.documentfoundation.org/ReleasePlan#4.0_release)

(In reply to comment #3)
> Which LO version do you use? FYI, last one is 4.0.2 and 4.0.3 is gonna be
> released in a few days (see
> https://wiki.documentfoundation.org/ReleasePlan#4.0_release)

Actually this has been since I've been using LibreOffice Base with Oracle DB.
Now I'm using version 4.0.2.
As soon as possible I'll change to version 4.0.3 but the change log doesn't describe any feature change.

josef: thank you for your feedback. I'll put 4.0.2 for the moment for Version field.
About 4.0.3, it was just for information, I don't know if something related to your problem has been modified/fixed in this version.

I think, this would be a major feature change.
I have so many DB-objects, that this kind of modification would be a glance.

Josef: the fdo#57872 put in "See also" may interest you.

Lionel: should we consider it as a dup?

(In reply to comment #7)
> Lionel: should we consider it as a dup?

No. bug 57872 is about managing the "C++ to Java call overhead", while this bug is about less eager (more lazy) caching of metadata.

Lionel: Ok I thought (wrongly now I've read your feedback) that metadata should always be completely loaded and so that it was only due to the slowliness pb.

Alternatively, we could cache the metadata information in the file, and refresh it only on explicit request by the user.

That's what MS Access does (with "linked tables"). I find that rather suck and not that user-friendly, actually. So I think I'd prefer the lazy loading. Or maybe background loading?


Summary of ways improving this:

1) Load metadata lazily

2) Load metadata in background

3) Cache metadata (negative vote from me)

4) Load only metadata of tables that match the tables filter.


4) can be combined with any of 1/2/3, and should be the easiest. Setting "PropôsedEasyHack" for this point "4".

The behaviour that I complained about in bug 52027 sounds similar.  I observed it with an ODBC connection but L.E.M. commented that the problem is common to all backends.

By 2012-10-07 the problem was no longer evident.  I wonder if the current bug is something different or if my older problem has returned.

( I am almost of the net, so will be slow to contribute further.  Sigh. )

Terry.

(In reply to comment #11)
The problem of bug 52027 is still absent in master commit 6faa622
pulled 2013-04-19.  I conclude the the present bug is something
different, and my earlier comment is mere noise.

In order to limit the confusion between ProposedEasyHack and EasyHack and to make queries much easier we are changing ProposedEasyHack to NeedsDevEval.

Thank you and apologies for the noise

Adding self to CC if not already on