I was looking at the asset and primitems tables as I was creating and editing a script. Here are my observations: <a href="http://spreadsheets.google.com/ccc?key=pQNviCc1baviZC2ic2vEgKA&hl=en">http://spreadsheets.google.com/ccc?key=pQNviCc1baviZC2ic2vEgKA&hl=en</a><br>
<br>I'm wondering is there a reason to duplicate the asset with new keys? Would using foreign keys help to track assets that aren't being used anymore?<br><br>Thanks!<br>BlueWall<br><br><br><div class="gmail_quote">
On Sun, Feb 8, 2009 at 6:32 PM, Teravus Ovares <span dir="ltr"><<a href="mailto:teravus@gmail.com">teravus@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
hmm, well, I also note that terrainimages are used for the in-world<br>
map currently<br>
<br>
Best Regards<br>
<font color="#888888"><br>
T<br>
</font><div><div></div><div class="Wj3C7c"><br>
On Sun, Feb 8, 2009 at 6:09 PM, Melanie <<a href="mailto:melanie@t-data.com">melanie@t-data.com</a>> wrote:<br>
> Hi,<br>
><br>
> Charles Krinke wrote:<br>
>> Each terrain edit appears to create a new "terrainImage" entry<br>
>> in the assets table and each time that happens, all previous terrain<br>
>> images become unlinked, unusable and unnecessary.<br>
><br>
> As I mentioned in a separate post, I have a map that uses these<br>
> terrain images. Removing them would render the map unusable. I<br>
> believe thet region servers have better things to do than server<br>
> thousands of requests for their terrain image and that that sort of<br>
> HTTP traffic is not what a region server should have to endure, it<br>
> should serve a region, not be a webserver.<br>
> Therefore, a centralized store of terrain images is a good thing to<br>
> have. However, I do agree that the previous one can be deleted, if a<br>
> way can be found to do so safely.<br>
> Terrain images have the "Temporary" flag set, so should be safe to<br>
> delete when they are 1 day old and not referenced from the Regions<br>
> table.<br>
><br>
>> A similar thing happens with scripts, notecards, and clothes.<br>
>> Prims themselves are stored in the regions datastore, so they<br>
>> dont apply to this discussion.<br>
><br>
> These items are implicitly shared, therefore you can't just delete<br>
> the old version; someone may hold an inventory item with a link to it.<br>
> That is the inherent dilemma with the LL way of asset handling.<br>
> There are two basic approaches: A one to one asset<->inventory<br>
> mapping with mutable assets; this will create a new copy of each<br>
> asset for each time it is used of referenced in a user;s inventory,<br>
> or the current, read-only, implicitly shared asset architecture. The<br>
> current viewer doesn't support mutable assets, so that is not a real<br>
> option at the moment.<br>
><br>
> Avoiding asset proliferation is not really possible at this time, so<br>
> I believe that pruning assets is the avanue that has more options<br>
> and that should be investigated.<br>
><br>
> Melanie<br>
><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br>