Difference between revisions of "Inventory OS"
(Added Kelly Linden's explanation of inventory storage from SLDev mailing list on 20 May 2008) |
|||
| Line 1: | Line 1: | ||
{{OSWikiFeatureNav}} | {{OSWikiFeatureNav}} | ||
There are three systems involved here that are closely tied: | |||
* (DB) Resident Inventory lives in a database. We currently have lots of these 'inventory' or 'user' databases, each one hosting the entire inventory for a subset of our users. ex. UserA has all their inventory on db1, UserB has all their inventory on db6. The database entries are the shortcuts / links to actual assets. | |||
* (ASC) The actual assets live in the Asset Server Cluster. Any item in resident inventory or object inventory references an asset stored in the Asset Server Cluster. | |||
* (SIM) Items rezed and 'in world' do not have an asset that reflects their current state. They do have an 'original asset' reference, which points to the asset used to originally create the item when it was read but this won't reflect any changes made since rez. We don't save individual items that are currently in world to the asset server or any inventory database. We do save the entire state of a region every hour as a 'sim state' file - and this includes objects and their inventory items (as references to actual assets). | |||
So, resident inventory lives in the (DB) and each item references one or more assets in (ASC). Object inventory lives in (SIM) and each item references one or more assets in (ASC). Items actually in world don't really reference any asset in (ASC) or anything in (DB). Keeping items inside the contents of objects in world and *not* in your inventory reduces the load of (DB) and may help keep your inventory loading faster, depending on how much you do it. It doesn't have any effect on (ASC) load though. | |||
=== Feature Design Document === | === Feature Design Document === | ||
Documents needed: | Documents needed: | ||
Revision as of 07:15, 21 May 2008
There are three systems involved here that are closely tied:
- (DB) Resident Inventory lives in a database. We currently have lots of these 'inventory' or 'user' databases, each one hosting the entire inventory for a subset of our users. ex. UserA has all their inventory on db1, UserB has all their inventory on db6. The database entries are the shortcuts / links to actual assets.
- (ASC) The actual assets live in the Asset Server Cluster. Any item in resident inventory or object inventory references an asset stored in the Asset Server Cluster.
- (SIM) Items rezed and 'in world' do not have an asset that reflects their current state. They do have an 'original asset' reference, which points to the asset used to originally create the item when it was read but this won't reflect any changes made since rez. We don't save individual items that are currently in world to the asset server or any inventory database. We do save the entire state of a region every hour as a 'sim state' file - and this includes objects and their inventory items (as references to actual assets).
So, resident inventory lives in the (DB) and each item references one or more assets in (ASC). Object inventory lives in (SIM) and each item references one or more assets in (ASC). Items actually in world don't really reference any asset in (ASC) or anything in (DB). Keeping items inside the contents of objects in world and *not* in your inventory reduces the load of (DB) and may help keep your inventory loading faster, depending on how much you do it. It doesn't have any effect on (ASC) load though.
Feature Design Document
Documents needed:
- Coalesed object returns.
- Declined inventory offers should be routed to your Trash.
Functional Spec
Test scripts
Container Permissions internal test
- Coalesed object returns?
Discussion for future improvements
Relationship to other features
List of features that need to be tested when this feature changes, and why.
Notecards Test - Notecards can hold inventory items(not calling cards) if their next owner permissions are fully permissive.
LLGiveInventory Test - Object Contents is inventory.
Group Permissions Test - Group Object Contents.
Inventory Permissions Test - Make sure the permissions are correct.
Item Permissions Test - Make sure the permissions are correct.
Next Owner Permissions Test - Make sure the permissions are correct.
Scripted Permissions Test - A different kind of permissions, but applies to attachments. (Scripted permissions really needs a name change to distinguish them from modify, copy, transfer permissions)