Hi Éric, > Speaking about housekeeping: > - half of the drivers put their include files in > connectivity/inc/<driver>/ > - the other half (including kab) put them in > connectivity/source/<driver>/ > What is the correct location?
I tend to source/<driver>. Usually, the rule is that you put into inc what is needed by more than one party only. On the other hand, with a certain complexity, this means your driver directory becomes crowded. In this cases, separating headers and implementations into different directories makes sense. When this limit is reached is heavily a matter of taste ... > Yes, that's the semantics of the methods, and it's quite easy to understand. > That was not the purpose of my question. The problem is that I need practical > tests to check that it works, once I have written it. Writing code and not > knowing how to test it is a bit of a problem... The more precise answers would require more fine-grained questions :). That is, I could, for most of the properties/interfaces/services, say which UI functionality would trigger their invocation, but there cannot be a general answer, and there is no general "test all my driver functionality"-tool, sorry. > Perharps I can just put some spies around in the code and try to see when > those methods are called. I can also grep the source tree for calls to these > methods. Or I could write some external java code that directly queries the > driver. Therefore, with some work, I can end up with good tests, but I was > just asking, in case you had some immediate answer ;-). qa.openoffice.org has a Java-based API test framework (OOoRunner, if that's still the current name), if you want to go this way. > As already said, this redundancy is rather surprising. Programmers are > usually > big fans of Occam's Razor (http://pespmc1.vub.ac.be/OCCAMRAZ.html) and it's > rather surprising to have to implement several times the same method in > various classes. If I understand well, this redundancy is intended for the > comfort of the programmers who use the API? The redundant parts of SDBCX: yes. Basically, they're allow more fine-grained object-oriented work. The non-redundant parts provide extra functionality, but sometimes, they imply the existence of redundant parts. For instance, a dedicated object for a table container could implement the XAppend interface, allowing to create tables described by a TableDescriptor instance. This abstracts from the concrete SQL syntax which you usually must know for creating a table. Thus, if for a given backend the syntax is non-standard, the driver will want to implement this framework, so the high-level UI can provide a generic creation mechanism without knowing the backend details. However, having a table container and table descriptors also implies having sdbcx.Column instances - even if those are completely redundant, and don't provide any extra functionality. >>However, if your driver works in the UI, then chances are high that all >>(implicit and explicit :) requirements to a driver are fulfilled. > > Yes, but that's like throwing dice... :) Sure, that's not really satisfying, but sadly the best I can offer here. >>But if your driver procides an (no-op) implementation for user >>administration, the UI will be tempted to use it - and result in a >>non-functional UI. This is probably not what you would want. > > Aha. Does that mean I would better _not_ implement a User service? Yes. The "non-redundant" parts of SDBCX should only be implemented if they provide real value. > Yes. Another related problem I have to look that is safety against concurrent > access. > ... > Currently, I have a in-memory copy of the address book at the time of opening > (remind: an address book is much smaller than a MySql database). While it's > okay for browsing the address book as it was at a given point of time, it > would require closing it and reopening it to refresh it :-((. I know that e.g. Calc driver does it the same way, but I would suggest another approach - exactly because with the current infrastructure, it's hard (up to impossible) for a user to explicitly *refresh* a table view. There's simply no API to pass such a request, obtained from the user at the UI, to the driver. Caching is done by higher layers, too. The already-mentioned RowSet service, for instance, is the base for nearly everything in the UI where any table/query data is displayed. This service also does caching, but it can be told to refresh its content (basically, this happens when the user pressed the "Refresh" button in the UI). So, there is not really a need for a driver to do caching. In the most simple case, it could provide a forward-only cursor, and access to column content of the current row of a result set. In a more sophisticated version, it would provide a more featured cursor which allows free movement, updates, and the like, but internally still does not do any caching. Then, concurrency wouldn't be a great problem anymore: Simply query the KAB every time your cursor is moved to another record. Just intelligently decide how this "other record" maps to a specified address. This might include deciding that the address to move to was deleted independently (XResultSet::rowDeleted) - though I am not sure how gracefully OOo's UI would handle this in every possible case :) Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
