On 4/4/11 23:34 , Paul Merlin wrote:
libraries/sql
=============
The new DataSource handling code pushed by Rickard has many advantages over the
old one:
- support the CircuitBreaker pattern
- expose configuration and restart operations through JMX
On the other side this new code is actually coupled to C3PO. The old code
provide DBCP and PostgreSQL pool implementations, it would be nice to have that
too with the new code.
My previous experience with DBCP is that it's not 100% reliable (weird
hangs in production), which is why I switched to C3P0. So with regard to
C3P0 vs DBCP I think only supporting one is fine. Is there any distinct
advantages with using the PostgreSQL pool implementation, over C3P0? If
so that could be made pluggable I suppose.
What would need to be backported from the old code too is
the ability to import DataSources (I need this for an application where
DataSources are provided by a JEE container).
Right. Something like the MBeanServerImporter should suffice I think,
i.e. just look it up and provide straight, possibly with a circuit
breaker wrapped around it. Yes?
The Databases class that contains utility methods seemed ackwards to me. On one
hand, methods that allows to work with ResultSets using the Qi4j I/O api are
nice, on the other hand we could get rid of the methods using strings for
statements. The java-sql-generator [1] library we use in entitystore-sql and
indexing-sql allows to write SQL without using strings at all.
Alright, that seems to make sense. Would it be ok to support both
strings and the java-sql-generator?
entitystore-sql
===============
Since we refactored the code to use java-sql-generator, Apache Derby is not
supported anymore. Because of this I @Ignored the unit test against Derby today
(it was alredy deactivated but with code). All in all we don't have anymore unit
tests that are run in the default build against a database, in other words, all
entitystore-sql unit tests are @Ignored. I don't feel comfortable with this.
Agree.
Plus, ATM entitystore-sql do not leverage the Qi4j Cache API. That would be a
great addition.
+1
indexing-sql
============
I do not use this extension myself so I can't say a lot appart from the fact
that in the default build there are no unit tests running for real against a
database.
Only one implementation of indexing-sql is available for PostgreSQL. Once java-
sql-generator will support Apache Derby we could work on the Derby impl and have
unit tests in the default build (ie. without having to set up an external
database).
Yes, that would be good. Derby with in-memory database is handy for testing.
I think I can handle the refactor about DataSource myself but I can't give a
timeframe as I'm working day& night actually. Will try to find the time asap.
Let me know if you need any help.
@Niclas& @Rickard: Do we try to put that in 1.3 final? What would be a
reasonable deadline for this to be in the final 1.3?
Like Niclas I need a final ASAP, to ship with Streamflow due to be
released this or next week.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
