Hi,
> multiple connections
> from a connection pool.
I understand. It's probably not a good idea to open a new connection
for each operation, because for some databases opening a connection
takes very long. I have implemented a simple pool (with maxSize) now,
I like to test it a little before committing it.
It probably makes sense to make the class extensible, but I don't know
yet where exactly this should be. I will make all methods and
variables protected.
If possible, I like to avoid creating a new class for each database
type, but if this is required only few methods should be implemented
there.
> I tested with SQL Server 2005 with the default statements, and they don't
> work because the BLOB data
> type is called IMAGE there. I changed it and everything else works fine.
OK. So the bugfix is to replace sqlserver.properties with:
driver=com.microsoft.sqlserver.jdbc.SQLServerDriver
createTable=CREATE TABLE DATASTORE(ID VARCHAR(255) PRIMARY KEY, LENGTH
BIGINT, LAST_MODIFIED BIGINT, DATA IMAGE)
Is this OK?
> No, it's not required, but if all you want to do is change the table name, I
> think it's too much having to re-write all the statements.
I don't understand, why do you want to change the table name specially
for one database type? Or do you mean make the table name
configurable? That does make sense (if you want to store it in another
schema for example). Should I implement the ${schemaObjectPrefix} as
you have done?
> Same goes for something as simple as changing BLOB to IMAGE
> in only one statement.
I think it's OK add the whole create table statement to the configuration file.
> Session.save() - various calls to DbDataStore.getRecord() and
> >> DbDataRecord.getStream()
> Just doing the following in a class that extends AbstractJCRTest is enough
>
> Session session = helper.getSuperuserSession();
> Node root = session.getRootNode();
> root.setProperty("notice", new FileInputStream("NOTICE.txt"));
> session.save();
OK thank for the test case! I didn't have time yet to find out how to
solve this performance problem.
> calls usesIdentifier() at the end of addRecord()
> better it as soon as the definitive identifier is available?
You are right! I will fix this.
Regards,
Thomas
