Hi Noel, I'm revising the patch following your suggestions. I have two doubts: 1. Could you please give me a hint on where the parameter /CACHE_SIZE/ is loaded from the JDBC URL? I still don't understand why /JAVA_OBJECT_SERIALIZER/ gets discarded from JDBC url derived settings while /CACHE_SIZE/ works properly . The setting is simply declared as available into /SetTypes.java/ and processed into /Set.java/... I've removed /javaObjectSerializer/ from /DBSettings/ in order to see if it makes difference, but it seems not enough.
2. I've also added the same new error code message to //h2/src/main/org/h2/res/_messages_en.prop/ and //h2/src/docsrc/textbase/_messages_en.prop/ as they are both under version control... maybe one is derived from the other? Cheers Davide Noel Grandin wrote > On 2013-08-02 12:31, davide.cavestro wrote: >> Hi Noel, I ventured into implementing the /JAVA_OBJECT_SERIALIZER/ >> command... >> just to try :-). >> So I would end up with three ways to set a serializer: >> 1. at jvm level >> 2. at db level through the jdbc url >> 3. at db level in a persistent way through the /SET >> JAVA_OBJECT_SERIALIZER/ >> command. >> That makes sense to me, as it covers various scenarios. > 1. is the existing flag, so we need to keep that. > 2. and 3. are the way a lot of the current options work, so that is good. > >> Now, I just wonder how a property set into the JDBC url can be exposed >> through the/ConnectionInfo.getDbSettings()/ implementation that actually >> does the following >> >> I suspect this way a well known property set through the JDBC url will >> never >> be added to the /s/ map, hence will never appear within the returned >> /DbSettings/ instance. Is it a bug? Please correct if I am wrong. > Have a look at how CACHE_SIZE works. > It can set either on the URL or using a SET CACHE_SIZE command. > And it is initialised in the org.h2.engine.Database constructor, which > is how this feature should be working > - it should read the name of the ObjectSerializer, and if it is > non-null, it should resolve the class via Class.forName at this point in > time. > >> >> In the meantime I developed the code that exposes to the /RemoteSession/ >> the >> /JAVA_OBJECT_SERIALIZER/ value eventually set into the database. It >> issues a >> "SELECT * FROM INFORMATION_SCHEMA.SETTINGS" query to the server, >> extracting >> the appropriate value. Is it adequate? > > Yes. > Have a look at the JdbcDatabaseMetaData#getMode() and > JdbcConnection#getQueryTimeout methods. > They do similar things. > > You should probably be reading the setting in the > SessionRemote#connectServer method. > > -- > You received this message because you are subscribed to the Google Groups > "H2 Database" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to > h2-database+unsubscribe@ > . > To post to this group, send email to > h2-database@ > . > Visit this group at http://groups.google.com/group/h2-database. > For more options, visit https://groups.google.com/groups/opt_out. -- View this message in context: http://h2-database.66688.n3.nabble.com/Database-level-custom-serialization-for-columns-of-type-OTHER-patch-proposal-tp4026990p4027073.html Sent from the H2 Database mailing list archive at Nabble.com. -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/groups/opt_out.
