You do realise you could just not update the asset. If the hash is the same, then you can just completely ignore the save/update request.
That being said, even a targeted collision on MD5 is a 2^58 chance, on SHA256 it's well over 2^128 which makes it pretty much impossible. Frankly it's not something worth concerning oneself over. Adam > -----Original Message----- > From: [email protected] [mailto:opensim-dev- > [email protected]] On Behalf Of Melanie > Sent: Monday, 16 February 2009 4:45 AM > To: [email protected] > Subject: Re: [Opensim-dev] Please do not revert fixes without careful > comtemplation > > Again, I'd like to stress that I believe this is too dangerous to do > for anything other than textures. > It is also not really needed for things other than textures, since > the other assets are comparatively small, textural data. > > I would not want to risk even the smallest chance of a hash > collision on script source. > > Melanie > > Stefan Andersson wrote: > > Coming in a bit from the side here, > > > > > > > > we have, for some time, discussed to separate out the binary blog out > of the metadata for an entirely different reason, namely to be able to > weed out binary duplicates. > > > > > > If there was a way for us to separate out the binary parts, into > something like 'binaryassetId, hashData[256], binarydata' and then just > have the asset table referencing that row, I think it would help a lot. > > > > > > I realize it's a separate discussion, just chipping in my two cents. > > > > > > Best regards, > > Stefan Andersson > > Tribal Media AB > > > > > > > > > > > > > > Date: Sat, 14 Feb 2009 17:49:22 +0200 > > From: [email protected] > > To: [email protected] > > CC: [email protected] > > Subject: Re: [Opensim-dev] Please do not revert fixes without careful > comtemplation > > > > > > Hello, > > > > On second though we could keep the current structure and expose all > fields also through AssetBase properties. Then we could save / load the > AssetBase with nhibernate as a single object and leave out the Metadata > property from NHibernate mapping. Does this sound good? > > > > regards, > > Tommi > > > > > > On Sat, Feb 14, 2009 at 5:06 PM, Mike Mazur <[email protected]> wrote: > > > > Hi, > > > > On Sat, Feb 14, 2009 at 4:05 PM, Tommi Laukkanen > > > > <[email protected]> wrote: > > > >> I was talking with mikkopa and he suggested we should create two > tables to > >> cover AssetBase to solve this issue properly. Namely AssetMetadata > for > >> metadata information and AssetData for blobs to avoid situation > where we end > >> up accessing also the blob data just to read metadata. > > > > I was hoping not to have to do that. > > > > It should be straightforward to support the current > > AssetBase/AssetMetadata composition in the existing OpenSim data > > layers, but as sdague warned me earlier, by mapping multiple classes > > to one table I was entering a world of pain. Seems that's exactly > > what's happening with NHibernate. > > > > The reason I introduced the AssetMetadata class is to supply metadata > > information only for some requests that Cable Beach, the new asset > > server, supports. Now I realize that this was probably a premature > > optimization. > > > > Instead of modifying the DB schema, we could have AssetBase inherit > > from AssetMetadata, as I outlined before[1]. Alternatively, we could > > get rid of AssetMetadata altogether and store everything in AssetBase > > as before, splitting out the metadata sometime in the future when a > > use case warrants it. > > > > What do you think? > > > > Thanks, > > Mike > > > > > > [1] https://lists.berlios.de/pipermail/opensim-dev/2009- > February/004918.html > > > > > > > > > > --------------------------------------------------------------------- > --- > > > > _______________________________________________ > > Opensim-dev mailing list > > [email protected] > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
