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.
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. 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? Cheers Davide Noel Grandin wrote > Thanks, this is nice work. You're mostly on the right track. > > Comments > > - unit testing seems a little light. I don't see any new unit tests that > actually use this new feature. > I'd expect at least one that actually uses the setting. > > - rather than storing a new javaObjectSerializer field in > ConnectionInfo, it should be stored both in Database and in > SessionRemote, along with all of the other configured stuff. > > - rather than modifying the SessionInterface class with a > getConnectionInfo() method, > expose a new method getJavaObjectSerializer() on the DataHandler > interface. > This is the preferred place for these kinds of things. > Not very well named, I know :-) > > - I don't see any new documentation. I think > src/docsrc/html/advanced.html would be the best place to put some > minimal documentation. > > - ideally, we'd want a new database setting command, which should > probably work like SET COLLATION i.e. it can only be executed before any > tables are defined. > see http://h2database.com/html/grammar.html#set_collation > and the logic in the org.h2.command.dml.Set class and the > Parser#parseSetCollation() method. > But I'm happy to add that part in later if you're not comfortable > with that section of the code. > > On 2013-07-25 13:03, davide.cavestro wrote: >> I need a way to use custom serialization (kryo based) only for a certain >> H2 >> db, while other dbs (on the same JVM instance) should continue using >> standard serialization. >> I've seen some time ago a guy asked something similar >> <http://h2-database.66688.n3.nabble.com/Serialized-vs-not-serialized-objects-and-system-property-td4024656.html> >> but no patches followed. >> The possibility to control serialization per-database is useful >> especially >> when you have no full control on jvm system properties (e.g. with web >> containers). >> >> So patch.txt >> <http://h2-database.66688.n3.nabble.com/file/n4026990/patch.txt> >> is a raw >> proposal that would let me benefit from the performance improvements I >> depicted in a previous post >> <http://h2-database.66688.n3.nabble.com/Any-chance-to-achieve-better-performances-for-OTHER-columns-through-jboss-serialization-library-tp4026037p4026809.html> >> . >> >> Some implementation notes: >> * changes are quite invasive: I exposed the /JavaObjectSerializer/ >> eventually specific to the particular db through /ConnectionInfo/ in >> order >> to make java object value holder classes operate on a per-db basis. OTOH >> I've not figured out any other minimal way to achieve per-db >> serialization. >> * I added the new optional database-level setting >> /JAVA_OBJECT_SERIALIZER/ >> (default: null) in order to specify the FQN of JavaObjectSerializer >> implementation used to (de)serialize columns of type OTHER. >> * I overloaded /Utils.serialize()/ with a signature that accepts an >> optional >> /ConnectionInfo/ and I supposed to deprecate the older signature. The >> same >> stands for deserialization. >> * The serialization still depends on the value of >> /SysProperties.serializeJavaObject/ (a system property). Maybe it could >> be >> masked by an ad-hoc new database-level setting... >> * I adapted the existing tests and added /TestPerDbJavaObjectSerializer/ >> >> Cheers >> Davide >> >> >> >> -- >> View this message in context: >> http://h2-database.66688.n3.nabble.com/Database-level-custom-serialization-for-columns-of-type-OTHER-patch-proposal-tp4026990.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 > 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-tp4026990p4027041.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.
