[Opensim-dev] Please do not revert fixes without careful comtemplation

[Charles Krinke]

Sorry, the other assets are not just "small texture data". We have terrainImages, amongst other things.

Our assets table in OpenSim contains lots of things including the infamouse "blank", so lets look at it in total and not just from the script viewpoint. 

Course with scripts themselves, we have every edited version of every edited script in addition to every change of every other asset complicating the problem.

Charles




________________________________
From: Melanie <melanie at t-data.com>
To: opensim-dev at lists.berlios.de
Sent: Monday, February 16, 2009 4:44:56 AM
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: tommi.s.e.laukkanen at gmail.com
> To: mmazur at gmail.com
> CC: opensim-dev at lists.berlios.de
> 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 <mmazur at gmail.com> wrote:
> 
> Hi,
> 
> On Sat, Feb 14, 2009 at 4:05 PM, Tommi Laukkanen
> 
> <tommi.s.e.laukkanen at gmail.com> 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
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090216/45ce9baa/attachment-0001.html>