Taisha Emerald

Sold

Grandfathered / Buy Down Homesteads for sale, full transfer. Lower tier (95USD) due the 14th of each month. 300 USD + 300 USD transfer fees to keep grandfathered / buy down status and lower tier which comes with. Please IM me, Taisha Emerald, in-world or start a live chat with me if you are interested.

After testing, it seems that the kvp store is sorted by insertion/update order, which is fine and makes my last post useless and answer my first question. However, the ability to sort the db in different ways should be really great.

In order to manage the data base size, we again need to retrieve all the key-values, or read them, to after sort all by date, list the older and delete them ? Or periodically check all key-values and delete older than X months by last update date? And case, if you consider that you have stored the key-value creation/update date in the value it mean that you must : get the number of keys, get the name of keys, read the keys, Json parse the values, and eventually delete a bunch of key-values, and this if you have thousands of players in your experience?! That doesn't mean huge functions calls, resources/memory usage ? I pain to figure how to manage a disordered data base you can't sort in any way without retrieving all the data, please bring me a light !

Thank you Lucia ! So if I understand well, as Oz Linden commented on JIRA "This is not feasible for performance reasons. The key/value store in unordered, and in the general case cannot be made ordered." So now my question, if I can not really interact with the db without retrieving all the data to simply sort players scores, why I would use the Experience Persistent storage instead of directly store and sort everything on my servers? Maybe I didn't yet matched the way it has been made for, at least it will be useful to store the players assets, but not their scores...

How are sorted the key value in the db? By creation order? Update a key value change its storage position? At what I understood there's no way to sort the key-values directly in the db, and it must be done by a script, which makes me think that the script must retrieve all the data to, as example, sort players by scores to make ranks, or I missed something... I don't know if it's technically pertinent, but it should be great to be able to sort the key-value pairs of an experience directly in the db (maybe using the values to sort key-value pairs, or being able to sort by keys or by values?) The need of a script to simply sort the data makes me think that we'll still need an external db, to do the job an easiest and faster way, but maybe I am wrong...

Welcome in-world Rod ! Nice to see you begin with build and scripts and I hope you will look forward in the Second Life creative process, the possibilities and what we can need. Also, get a look at the shopping/merchandising tools in-world and online and learn how residents really use to them should be a positive experience. (translation from french)

" think long and hard about allowing residents to PAY to make their name unique again in SL. A one time fee of a serious amount, say 5-10KL$, so make it so the database will not allow their name as a display name." It looks like racket but I agree with the idea if we don't have an other choice for save our name...

Behind the display name a real problem of griefing, for a merchant compromise it's name can be a disaster for his buisness. The ability to lock our username and disallow others residents to use it as display name should be a solution. And about the scripts...I read this attention the article of the LSL wiki ; well we'll have new functions and some others will be broken and scripts will need to be updated (I think about name based sensors for exemple), and what will happen with third party viewers? it's occurs differents ways and choices of developement in the future for the scripters : add a switchable display name compatibility? Occurs also many complications in name based systems as you can see on the wiki page, and the new function llGetDisplayName will fail sometimes as you can read on the page of the wiki "It may take up to 72 hours for a display name change to take effect. During this time scripts may report the old display name and viewers may see the old display name." So I am really worry about the display name usage as a griefing tool and also the final implementation in LSL.