You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Mike Chase — Today at 4:52 PM
It is a key value store and I'd probably use json for the representation internally. But the api is fetching values given a key so pretty simple to do with json and string in the database
Balpien Hammerer — Today at 4:52 PM
Yes, the architectural spec, which is K/V oriented, should be followed, though not
necessarily a key/value implementation in the sense of a database.
The fact there is a limit to the size strongly suggestions a serialized json implementation, just like High Fidelity did.
And, this makes it clear its serialized in the root prim: ..."It is possible for data to be rolled back to a previous state if the datastore is stored in an object that is restored via a simulator rollback, or in an attachment that is not properly saved back to the server on logout...."
Mike Chase — Today at 5:56 PM
Just adding that there is a "JsonStore" implementation in OptionalModules that could probably be adapted.
The text was updated successfully, but these errors were encountered:
The underlying stored data could be a JSON string and additional functions to just store and fetch the JSON string could be added. The llLinkset* functions would be just operations on the JSON string. There could be a JSONPath operation on the JSON string also.
Am implementing this. The prims table will have a mediumtext field, LinkSetData default NULL. The linkset data is stored in the root prim (linkNumber 0) as a json string. This data is decanted into an ordered associative list on SOG instancing and reserialized on SOG persist. All other operations act on the in-memory list.
Tracking the off-topic comments to get SL's LinksetData into OpenSim. Here is the arch-spec:
https://wiki.secondlife.com/wiki/Category:LSL_LinksetData
Second Life Wiki
Mike Chase — Today at 4:52 PM
It is a key value store and I'd probably use json for the representation internally. But the api is fetching values given a key so pretty simple to do with json and string in the database
Balpien Hammerer — Today at 4:52 PM
Yes, the architectural spec, which is K/V oriented, should be followed, though not
necessarily a key/value implementation in the sense of a database.
The fact there is a limit to the size strongly suggestions a serialized json implementation, just like High Fidelity did.
And, this makes it clear its serialized in the root prim: ..."It is possible for data to be rolled back to a previous state if the datastore is stored in an object that is restored via a simulator rollback, or in an attachment that is not properly saved back to the server on logout...."
Mike Chase — Today at 5:56 PM
Just adding that there is a "JsonStore" implementation in OptionalModules that could probably be adapted.
The text was updated successfully, but these errors were encountered: