Hi Éric, > OK, I analysed the other drivers a bit more : > - only two drivers declare they offer the sdbcx.Column service (hsqldb and > mysql) > - there seems to be a Column class in only four drivers (ado, hsqldb, mozab, > and mysql) > - many drivers instantiate a sdbcx::OColumn (calc, dbase, evoab, file, flat, > and mozab)
Well, some drivers don't need a column class at all (as said, higher layers will emulate missing parts of the SDBCX API in a generic way, if not provided by the driver, or simply not provide certain functionality. For some drivers, there basic, shared implementation sdbcx::OColumn is sufficient. Those which extend it simply need to cope with some specialities of the underlying database, for instance, the MySQL column implementation needs to care for the auto-increment flag, which in MySQL is reflected as a appendix to the column type. I suppose that for the KAB driver, you can go with the shared implementation, perhaps even without a column. > Among ado and mozilla drivers, only the ado driver seems to be doing real > property management in class OAdoColumn. mozab/MColumn.hxx contains only two > constructor declarations. Hmm, looking into it: the column class in mozab is not even used (I'm going to remove it). I suppose the driver was copied from an existing one, without checking every bit for necessity, and so some superfluous bits came into being ... :-\ > OK. What I am still having a hard time to grasp is the final purpose: when > are > these properties queried in the driver? What happens if I do not implement > them correctly? How do I test this stuff? That's hard to tell in a generic way. I'd say that the behaviour certain UI elements (or even only certain core implementations in the SDB layer, which use your driver's objects) depends on those. For instance, if a column is able to tell that it's an auto-increment column, then whenever you enter data into the respective table (or a form based on it), the control representing this column will change to some "auto-value" field in a to-be-inserted record. The IsRowVersion property could be used to determine whether this column should be shown at all, if the "Show version columns" option for the database is not checked. And so on ... As said, especially for the sdbcx.Column service, it holds that there is a certain redundancy: Most (all? - not sure ATM) of the information can be obtained by other means, too (e.g. from the result set meta data, which is always needed). But having a dedicated service, fulfulling a certain contract which other implementations can rely upon, eases usage. > But I think I can answer these questions alone. Tracing the calls to > getFastProperty() or whatever should be a good way to start understanding > that. good idea :) >>>But never mind, that's not important. >> >>Oh. >>Well, nonetheless I tried to explain it :) > > Well, it *is* important to me ;-). But I don't want to burn too much of your > work time... Hey, the good news is: it's part of my job to answer such questions - I'm getting paid for it :)))))) >>There are not much use cases for using a driver directly. > > Hmmm... I can figure out a Basic macro or a Java program calling the driver > directly... Yes, but that's inconvinient. I always recomment using higher layers providing more abstraction. For instance, simply iterating through all records of a table of a database is quite some lines of code if you work with the driver, and the low-level driver-provided objects directly. If, on the other hand, people use an com.sun.star.sdb.RowSet service, this task is peanuts. And, also important, it's *compatible* then: If you want to iterate through records of a table of another databases, it's just the database name you have to change. If you do this directly with driver-provided functionality, the changes are much larger (for instance, you need to care for identifier quoting yourself, and things like those). That said: Yes, API developers *could* work with a driver directly, but usually, there are no advantages, only disadvantages when doing so. >>but also in the higher layers which usually encapsulate access >>to the drivers. > > What do you mean? Can you show me a way to test that? There are (sadly) no dedicated API test suites for database drivers, so I cannot really offer you something here. In theory, one could use the generic API definition, and check a certain implementation whether it fulfills all contracts required by the API it implements. However, something like this doesn't exist. Not to mention that the API documentation is, well, too sparse sometimes, and that I'm not even sure if all existent drivers would pass all tests then. Finally, the API is that complex, and full of if-then-else-but conditions, that it's difficult to test all of them, not to mention *implementing* them :-\ (Look at the XDatabaseMetaData interface, and imagine a test suite caring for all possible values of all possible meta data - and that's only part of it.) However, if your driver works in the UI, then chances are high that all (implicit and explicit :) requirements to a driver are fulfilled. > Please note that it's not too difficult to handle either. User management > results in no-operation, 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. > When you are like me a newcomer to uno, this weak coupling of components is > rather surprising. You are used to be _obligated_ to implement pure virtual > functions, and to be happy to be _able_ to implement simple virtual > functions. There is no such thing like "oh, and there is another interface I > could implement". :) Never saw it this way, but yes .... > OK. the kab driver doesn't do currently update access, but I will certainly > do > someday. There is an "identificator" mechanism in KDE's address book which > would allow implementing primary keys, but bookmarks wouldn't harm either. Sounds like those identificators could be used as bookmarks, too. If you don't want them to be visible to the user (perhaps since they would be meaningless to him), then bookmarks are the better choice: They're a an additional column in a result set not reflected in the UI, and can be filled with driver-dependent values (nobody outside your driver will ever attempt to interprete them). 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]
