Le lun 28/06/2004 à 21:48, Yves Chaufour a écrit :

Il semble que ce soit un tres bon produit, ce qui est un peu genant c est le fait qu en mode partage (serveur) le resultat des requetes doit tenir en memoire (ou il faut jongler :(). Mais pour le responsable de dba ce qui passe en premier c est l usage en mode local qui n a pas cette limitation.

Pas encore eu le temps de tester, j avoue ne pas etre presse et attendre la decision d incorporation a la 2.0.

Bien sur, ce n etait qu une info, car je ne sais pas tres exactement ou vous voulez aller avec SQLite.

Absolument !

Pour info, voila un des dernier post, a ce sujet, du responsable de dba sur Marketing (un peu long mais interessant):

================================================== Hello Alex,

OOo

Yes. Not sure which side effects this may unveil - that's why it's "a certain risk".

The documentation said that BLOBs can only be stored if encoded, since you have to transport the BLOB as string.

http://www.sqlite.org/faq.html#q13

It's not the problem of getting an out-of-the-box SQLite running with OOo - I have this on my machine, too.

It's that we think it did not fit our particular purpose: modifyable (within a limited time frame) so that it can store its data into our database files, and having a certain set of functionalities.

Again: The architecture for this is planned in a way that later on, we can extend the feature with other database types to embed, even in a way that a package released long after OOo 2.0 can be deployed for OOo 2.0, refitting it with this new type [1]. For the moment, we decided to go for HSQLDB since it seemed more managable for this purpose.

And: It's not even clear whether we will be able to do this 'til OOo 2.0. The reason is that a goal we definately have is that any changes we do to the HSQLDB code base (to allow it storing data in virtual file systems, so we can re-route it to our database files) must be in a shape that they're accepted by the project when contributed back. The mid-term goal is that people can simply download the newest HSQLDB and use it with OOo, instead of downloaing a specialized HSQLDB-for-OOo version (bwt, this requirement would apply in exactly the same way if we'd go for SQLite).

This implies more work than a small and dirty solution, and when weighting priorities for a 2.0, we definately want to have one *working* feature (namely the new DB application) instead of two features (DB app and HSQLDB integration) which are only half working.

Thus, it may be that everything I said becomes groundless - for a post-2.0 version, decisions may be made on a completely different basis.

Ciao Frank

[1] In fact, SQLite would be my (personal) next choice, if we happen to do this (but it may be even done by "external" developers, there's no technical need at all for us Hamburg-based Sun-paid people doing this).

Jean Louis