Hi Éric, >>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. > > Yes, I had seen that. Isn't this framework supposed to be written by > different > people as the developers? (QA people)
Written: yes. Used: no. I really like to use it for testing API implementations. For examples, you could look at forms/qa/integration, which is where I collect form layer related integration tests of various kind (not that many, at the moment), based on this test framework. It's pretty easy to get started: just a few lines of Java code, and a makefile ... > My problem is that the driver relies on an existing API (kabc = KDE address > book connectivity). If I understand that API well, the only way to proceed is > to load the whole address book in memory, iterate through it, perharps add or > remove records, and save the result if modified. Therefore the "caching" is > imposed to me by the API. Ah, I see. > (1) Currently, they have a life term equal to the duration of a > PreparedStatement or of a Statement object. Which is rather short, if I > understood it well. A statement creates one or more result set during its lifetime. Formerly, it was usual to implement it this way that a statement holds all statements, and kills them when itself dies. Nowadays, the recommendation is that a result set should hold alive its statement, which eases usage via, e.g., scripting. The result set is held as long as some instance could need the data. In the UI, this means that your result set - and thus your statement, if you implemented life time control the right way :) - is held alive as long as, say, a table data view is opened, or a form based on this table. Which should be sufficient, since it means that at least when the data view is closed and re-opened (perhaps even when the user presses "reload", not sure ATM), the new data made by other parties is visible. Which is perfectly okay and expectation conformant for the user, IMO. >>Then, concurrency wouldn't be a great problem anymore: Simply query the >>KAB every time your cursor is moved to another record. > > That's precisely the problem: you can't query an isolated record (2), you > load > the whole address book at once. Please remind it is considered to be "small > amount of data", unlike usual databases. I see. Okay, in database terminology this means that your database meta data should return |false| form othersFooAreVisible methods ... Ciao Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
