A Delete Button

[No one]

[quote name='Rendril' date='03 November 2009 - 03:25 PM' timestamp='1257254714' post='46494']
I suspect there is a single function for it, but each scene could be checking for a key in its specific way.
I am not saying this is what it does, just a possibility.
I genuinely hope it is being checked in the preloader queries.



As far as I know, the cross-user storages are not finished yet.
Here is an example that uses all object, this user.
If you want it with all users, you will have to manage the user id's manually, it might be easier with just the ucrrent methods.
[code]
//get the stored "keys"
retrieve(@vk);

//make a new blank array if it doens't already exist
if(@vk == null)
@vk = array();

//giving the user a "key"
@vk[] = "my-key-name";

//checking if user has the "key"
if(in_array("my-key-name", @vk))
echo "you have the key!";

//save the "keys" back in storage
store(@vk);
[/code]

[/quote]

Ok, tell me this: when you do the "retrieve(@vk);", you are getting the "values / user" or "values / script owner" ?


[quote name='Rendril' date='03 November 2009 - 03:25 PM' timestamp='1257254714' post='46494']

I believe the MDStore and WPStore already work on keys.
We are assuming there is a global key-checking function. If there is, great. If not, it means a massive game overhaul.
[quote]
I just thought of this:

If there is already a function that checks the keys, then ... it can be done without too much problems to first check the initial way then to check in the tables.

That way, if the new way is better it can replace completely the old method without crushing the system.

[quote name='Rendril' date='03 November 2009 - 03:25 PM' timestamp='1257254714' post='46494']

That's not what I meant, I'm saying the tradeoff isn't good enough.
Please correct me if I am wrong in this estimation:

Most key lengths will not exceed 30 characters nor will they fall below 10 characters (taking prefix length into account) so we have an average of about 20 characters for a key, that means 20 bytes.

In the current method that means it is storing twice that due to the asoicative indexing, thus 40 bytes.

Can you explain why you gave 2 tables? I'm not sure why both are needed.
The way I see it these are the fields that would be needed:
key_id (long - 4 bytes)
user_id (long - 4 bytes)
editor_id (long - 4 bytes)
key_name (string - 20 bytes average from above)
last_access_timestamp (long - 4 bytes )
system_key_flag (boolean - 1 bit)

Usage per row = 36 bytes (I hve omitted the 1-bit boolean)

So, 40 bytes compared to 36 bytes.
This is a pretty big increase, 10% is no small matter.
In 1mb of keys we save 100kb.
But this is without taking into consideration the MySQL overhead, which does not come cheaply.
MySQL does its own indexing and storing of additional metadata tables for faster querying. This alone makes the table method cost more than the redundant key sotrage.
Correct me if I am wrong, but I think additional tables and indexing take much more than the 4 bytes saved.


Please don't misunderstand. I am in favour of the method you suggest.
I just haven't seen sufficient cause to warrant a massive migration.
If you can provide conclusive reasoning for how it is remarkably better, we can take it to Mur.
[/quote]

aaa ... aaaa, i guess so

The reason that I put 2 table is to try to remove the redundancies.
If there are 2 identical keys ... it will save space, if all the keys are different ... it will lose space.

As for 2 different tables ... well ... consider that actually there is an "n-n" relation between user and key. And that relation is done through the 3rd table : "user_keys".

Another reason for using tables ... it can speed up the search for keys, it will allow listing of keys / user or keys / owner or the other way around ( user / keys ).

As for space saved ... consider this : all armor, all WPShop, all MDShop as keys, lets say 200 items
200 * 20 chars average = 4000bytes for each player , but all these keys are stored once, after that , each one will only this : (uid, key_id, last_access_timestamp, system_key_flag) and all these columns only if you want to implement new functionality.
Also consider the new functionality that are opened with this approach, not only the space occupied.

Edited November 4, 2009 by No one

[Rendril]

[quote name='No one' date='03 November 2009 - 06:27 PM' timestamp='1257265621' post='46515']

Ok, tell me this: when you do the "retrieve(@vk);", you are getting the "values / user" or "values / script owner" ?
[/quote]
I depends on what you are storing. Other editors do not have acess to your storage, you can even name them the same.


[quote name='No one' date='03 November 2009 - 06:27 PM' timestamp='1257265621' post='46515']
I just thought of this:

If there is already a function that checks the keys, then ... it can be done without too much problems to first check the initial way then to check in the tables.

That way, if the new way is better it can replace completely the old method without crushing the system
[/quote]
Exactly, lets hope there is only one function



[quote name='No one' date='03 November 2009 - 06:27 PM' timestamp='1257265621' post='46515']
aaa ... aaaa, i guess so

The reason that I put 2 table is to try to remove the redundancies.
If there are 2 identical keys ... it will save space, if all the keys are different ... it will lose space.

As for 2 different tables ... well ... consider that actually there is an "n-n" relation between user and key. And that relation is done through the 3rd table : "user_keys".

Another reason for using tables ... it can speed up the search for keys, it will allow listing of keys / user or keys / owner or the other way around ( user / keys ).

As for space saved ... consider this : all armor, all WPShop, all MDShop as keys, lets say 200 items
200 * 20 chars average = 4000bytes for each player , but all these keys are stored once, after that , each one will only this : (uid, key_id, last_access_timestamp, system_key_flag) and all these columns only if you want to implement new functionality.
Also consider the new functionality that are opened with this approach, not only the space occupied.
[/quote]
Duplicate keys are not allowed, that is why they are stored in an associative array to begin iwith.

I see what you mean for the extra table with the compound key.

As I showed in the estimate above storing them in tables is likely to cost more then the current method.
Our desire to put them in a table at all, coems from the need for efficient key cleanup.
We accecpt that the deleting is happen infrequently.
So while it might save stoing a few unsed keys when it happens (for a large deletion cost) in the tiem that the quest is running, it will be used more resources. There are many quests that runs months without being finished, and some keys might be used for things indefinitely.

It just isn't showing itself ot be a good tradeoff.
In fact, from what I can see, the best action is to simply start storing the keys in an indexed rather than associative array. At key creation you run a loop inm linear time to detect a duplicate.

[Kafuuka]

[quote name='Rendril' date='04 November 2009 - 02:28 PM' timestamp='1257341303' post='46586']
As I showed in the estimate above storing them in tables is likely to cost more then the current method.
Our desire to put them in a table at all, coems from the need for efficient key cleanup.
We accecpt that the deleting is happen infrequently.[/quote]
We do? I never accepted that. And estimates about cost are quite depending on how efficient MD code is.

[quote]So while it might save stoing a few unsed keys when it happens (for a large deletion cost) in the tiem that the quest is running, it will be used more resources. There are many quests that runs months without being finished, and some keys might be used for things indefinitely.

It just isn't showing itself ot be a good tradeoff.
In fact, from what I can see, the best action is to simply start storing the keys in an indexed rather than associative array. At key creation you run a loop inm linear time to detect a duplicate.
[/quote]
If you really want to optimize it, you could always store a single boolean for each keyname: permanent. Only put the ones that are temporary into a second table that keeps track of uids for keys. Downside: you need two new tables (although a table of booleans is hardly expensive) and everytime a key is given, a check must be made if the keyname exists (if it doesn't you don't know if it is permanent or not) and whether it is permanent. If all key functions are global functions, this isn't difficult to program, but all currently existing keys should be registered, which seems like an annoying thing to do.

Anyway, this discussion seems to rely too much on what the current MD code looks like. Which means we'd better persuade Mur to read this.

[Rendril]

[quote name='Kafuuka' date='04 November 2009 - 09:31 PM' timestamp='1257363060' post='46628']
We do? I never accepted that. And estimates about cost are quite depending on how efficient MD code is.
[/quote]
You yourself said this would not be a frequent occurence.
Imagine scanning a table of 30k rows just to remove 1 key on a regualr babsis...


[quote name='Kafuuka' date='04 November 2009 - 09:31 PM' timestamp='1257363060' post='46628']
Anyway, this discussion seems to rely too much on what the current MD code looks like. Which means we'd better persuade Mur to read this.
[/quote]
Seconded.

[Kafuuka]

[quote name='Rendril' date='04 November 2009 - 08:36 PM' timestamp='1257363413' post='46630']
You yourself said this would not be a frequent occurence.
Imagine scanning a table of 30k rows just to remove 1 key on a regualr babsis...
[/quote]
Infrequent as in 'not every hour' yes, but frequent enough if you compare the number of keys purged to the total number of keys.

Actually, how long would a query on 30k rows to find all players that have one (or more) keys take? And for deletion (guessing that takes a bit longer).

[Rendril]

I think it's generous to assume it happening once or twice day.

Now that I think about it, it will be much more than 30k rows.
Each player has their own multitude of keys, I would guess no less than 5 at least, maybe 10 or more.
Imagine a table of 300k records...