[Opensim-dev] oddities with asset storage

[Buckaroo Mu]

Here's my L$0.02, for what it's worth - why not maintain a 'reference 
count' in the asset entry?

Resident A creates a prim, takes it into inventory. Asset is created, 
inventory item pointing to asset is created, asset->useagecount++. User 
gives away 15 copies of item, asset->usagecount+=15. Resident A deletes 
original item, inventory item goes away, asset->usagecount--.

Resident B rezzes item on sim. If item is no-copy, asset->usagecount--. 
If it's copy, and Resident B (or Resident C) takes it back into 
inventory, asset->usagecount++ (they would have two copies of it). 
Resident B deletes both copies from inventory, asset->usagecount -=2.

If asset->usagecount == 0, asset gets deleted.

Tell me why this wouldn't work. I'm sure there's a simple reason, but I 
can't think of it. All of this is assuming that the asset is no-mod - 
any change to the asset creates a new UUID, correct? But if the asset is 
rezzed, then taken back into inventory, it should have the same UUID, 
thus adding one to the usage count.

-Buckaroo

Melanie wrote:
> All you described is design behavior.
>
>
> Prim items in world are not assets. They are stored exclusively in
> the prims tables of the region.
>
> Once taken, they become an asset. The name is totally meaningless,
> it reflects whatever was the name at creation. Nothing else. It
> never changes from there on.
>
> On deleting the inventory item, assets remain. There is no easy or
> practicable way to conclusively say that an asset is trash, because
> we don't know.
>
> In your test case, your (human) mind could know this for a fact,
> however, the silicon mind of the asset server can't.
>
> This is because you may have given the object to another user, or
> put a copy into a prim.
>
> These copies would refer to the same asset, that is what "implictily
> shared" means.
>
> So, any asset may, at any time, have any number of links to it, even
> zero.
>
> Like a website, you don't know who linked to it. If you remove it,
> you leave dead links. Assets are the same. Except, you get "Asset
> missing from database".
>
> So, assetas are NOT 1-to-1 with inventory items, and they _never_
> get deleted.
>
> They have to be reaped, and there is a big discussion over how to
> best do that, running right now.
>
> Melanie
>
>
> Dirk Krause wrote:
>   
>> Hi,
>>
>> I did a little test with a fresh OpenSim installation (yes, thanks for
>> the installer!),
>> to get a grip on what I learned from Melanie yesterday.
>>
>> I wrote a little python script to help me monitor these tables:
>>   inventoryStore/inventoryItems
>>   assetStorage/assets
>> http://pastebin.com/mc9e6574 , be warned: ugly code.
>>
>> I started OpenSim and logged in a 'Test User' with the SL viewer.
>>
>> (Just to mention it - first time log in in as test users creates
>> 4 'blank' entries in assets.)
>>
>> The inventoryItems table was initially empty.
>>
>> Now I rezzed a cube and renamed it to 'p1'.
>> inventoryStore/inventoryItems was still empty.
>> To my surprise no new entry shows up in assetStorage/assets.
>>
>> Picking up the cube ('take') created an entry named 'p1' in the
>> inventory and in the asset table.
>>
>> Now I renamed the cube in Test Users inventory to 'p2'.
>> The name in inventoryStore/inventoryItems changes to 'p2'.
>> The entry in assetStorage/assets stays 'p1'. As mentioned on the list
>> before,
>> the asset name is useless, since the user only sees the name in the
>> inventory.
>>
>> Now I deleted 'p2' in my inventory - 'p2's parentfolderID changes to
>> 'Trash'.
>> Now I emptied the trash - the inventory table is empty again, which is
>> fine,
>> but here's the big one:
>>    the assetStorage/assets still holds the reference to 'p1'.
>>
>> Just to make sure I shut down the simulator and opened it again, and it
>> was still there.
>>
>> Now, doesn't that mean, that the database increases over time with no
>> hope to find
>> these assets that actually should be gone? or is there some magic
>> purging that happens,
>> and that I missed?
>>
>> This would mean that any grid runs into a severe problem over time.
>>
>> Best,
>>   Dirk/Bart
>> _______________________________________________
>> 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
>
>
>