Hi, El 29/10/10 10:04, Joonas Pulakka escribió: > On Oct 28, 9:19 pm, Thomas Mueller <[email protected]> > > The new "lob in database" feature does now use a > checksum (hash code), I considered using a cryptographic checksum, ... In > most cases it would slow down adding BLOBs too > much I believe.
> if a Java object to be serialized overrides equals(), it must also override > hashCode(), > which must be consistent with equals(). So if you stored that hash > code alongside with the object itself when storing OTHER types, > looking them up from the db using equals() comparison could be made > pretty fast, provided that the hashCode() of that particular class is > well-implemented: only instances where the hashcodes match need to be > actually unmarshaled and compared with equals(), like in a HashMap. > > Don't know what to do with classes that use the default equlas() and > hashCode(), though This case shows that the hascode, checksum or digest to be used must be own and calculated by the database at the time of insert / update of such data or perhaps by the method setObject()/OutputStream in jdbc driver on the client side. relieving the engine of this work in client/server mode. Repeating this calculation on server side enable integrity check of received data over the wire. Thomas's concern about the slowness of the calculation of a 128-bit digest could add to the operations of insert / update in large BLOBs could be irrelevant compared to the time to handle large data volumes. regards, Dario. -- 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.
