I do realize that: - OTHER type is language specific. - Comparing them (with equals or compareTo) would require deserializing each single row, which would be orders of magnitude slower than comparing primitive types. - Deserializing at the server side is as security hazard. - Therefore, in general, objects should be decomposed to their primitive types (as defined by some standardish SQL spec) in order to store them in a SQL DB.
Regardless, a quick 'n dirty comparable object "blob" would be quite handy in some embedded applications. Sometimes dumping a whole lot of information into the DB quickly without too much hassle is exactly what's needed. I was thinking to store java.io.File objects in the DB in an embedded application. The object, java.io.File, is essentially just a path String, but it includes a equals() method that tests for the equality of the "abstract pathname", that is, "C:\Users\me \file.txt" and "file.txt" are equal if working directory is "C:\Users \me\". Actually I now realize that maybe I'm better off storing just Strings from File#getAbsolutePath() as VARCHAR_IGNORECASE type. Decomposition done!:) The original question ultimately boils down to whether the author wants to keep H2 a "true & pure DBMS", or allow adding some goodies that are handy in some situations. Best Regards, Joonas On Oct 13, 6:53 pm, Rami <[email protected]> wrote: > While I am sympathetic to your cause I am not very happy about the OTHER > type. > Why? > Well, what happens when an other language accesses a column like that. > That issue is already concrete when using the ODBC connectivity from > let's say php. > Also there is an other type in jdbc spec called JAVA_OBJECT. > What the heck is that all about?!? > > I just feel that a true DBMS should be language neutral and define > a clear datamodel that everybody can understand and interpret. > > What is the literal representation of OTHER type's value? > When reading, it could be the output of toString() method but > would that work when inserting a value? > That would require a contract that the class has a constructor that > takes a single string value that constructs the same object. > > new Other(other.toString()).equals(other) == true > > Further should the OTHER type be also comparable (implement comparable > interface)? > > Are you sure you can't decompose the data that your object houses into > proper types in database? > Or are you just wishing to dump a whole lot of information into database > quickly > without too much hassle? > > - Rami > > > > Joonas Pulakka wrote: > > When using the OTHER data type (serialized Java objects), do > > expressions (i.e. NAME='Hi') compare simply the serialized byte array > > (for exact equivalence), or is the (deserialized) object's equals > > method used? If equals is not currently used, could it be added as > > feature request? > > > Thanks, > > Joonas -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
