Le Jeudi 18 Août 2005 08:52, Frank Schönheit - Sun Microsystems Germany a
écrit :
> 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.
OK. So it can be developed later, and the KDE address book driver won't be the
only one to do that ;-).
I have put at the end of my TODO:
"Write missing sdbx services: Column, User, etc."
> 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.
Yes, that's what is currently happening, the driver just does a
pRet = new sdbx::OColumn(many arguments);
in KColumns.hxx
This code is probably stolen^Hreused from some other driver, BTW.
> 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.
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'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 ...
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...
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 ;-).
> 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).
These ones are already implemented, yes.
> But having a dedicated service, fulfulling a
> certain contract which other implementations can rely upon, eases usage.
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?
> > 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 :))))))
;-))
> 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.
Understood. The only person to query a driver directly is probably... its
developer ;-).
> 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.
That sounds like a new (tedious) job for QA people ;-).
> 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.)
Urgh...
> 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...
> 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?
> 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),
Correct, they are purely technical.
> 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).
Yes. Another related problem I have to look that is safety against concurrent
access.
For example, the user could run KPilot to resynchronize contact lists with
his/her Palm Pilot device, when at the same time the address book is opened
in OpenOffice.org (method KabConnection::construct()).
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 :-((.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
