Hi, AFICS, such a feature would be targeted to most common uses of OTHER, STRUCT, JAVA_OBJECT, BINARY and BLOBS sql data types that are used as generic containers:
1) Serialized java objects 2) Files content on database ( images, documents content, etc) 3) UDT (db user defined types) - this is a very different animal - but the main target of OTHER and STRUCT sql data type. For serialized java objects , as you say, *the* option is to use this object class compareTo() involving object un-marshaling for each column/row, nice and useful but very expensive. For files contents would by needed a very different implementations using digests or full content comparison; and in this case only equals() seems to make sense on database side. An affordable and efficient equals() implementation for both cases could done using a resort similar to that used by RSYNC to determine differences between two files or binary blocks. (http://www.samba.org/rsync/tech_report/node2.html). This involves saving this "comparable" binary data with 4 bytes [or 20 bytes] of additional storage to contain a 32 bits checksum [ and a strong 128 bits MD4 checksum ]. The 32 bits checksum can be used for equals() fast fail ( even hashing or indexing ) and to select equality candidates, that are reduced with a second round comparison of their the 128 bits MD4 checksums or by a byte[] full comparison. With an implementation like this we make possible searching by equality on today "dead" binary data, that is not an small thing Any other more advanced approach require UDT with used defined operators implementation but this is a very big target. Let me know you thoughts about this. Regards, Dario El 24/10/10 12:08, Joonas Pulakka escribió: >> Or would you call the objects toString() >> method and use String compare? In that case the security problems are >> relatively low I guess. > I've already worked around my particular case, but the original idea > was that using equals() and compareTo() comparisons would be a logical > extension to the ability of storing arbitrary objects in the DB (via > serialization). But this would require converting to actual objects in > the server side in order to compare them, and it's definitely a > performance issue, and also a security issue (although it really > depends on who's allowed to put what in the DB). I'll keep thinking if > I come up with some ideas, but currently I'm not sure if this feature > request is that good after all. > > Doing it via toString() would be adequate for objects whose String > representation fully describes the object (i.e. a fromString() factory > method could be used to reconstruct the objects), but if that's the > case, then it's probably better to just store Strings in the first > place > > 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.
