General info requested on system lookup values

[jimmo]

Greetings!

I am in the process of converting my phpgroupware projects to dotProject. I discovered the wonders of the "System Lookup Values" and wanted to change some of the values, add some more and so forth.

I was wondering if there were any problems with skipping values. For example, I wanted to add a few entries to ProjectStatus and change "Template" to value 99, so it would always be separate from the other "real" statuses. Therefore, no matter what other statuses I added, this would always be the last one.

Is this possible. Does it even make sense to do this? Any input is greatly appreaciated.

Regards,

jimmo

[pedroa]

If you watch the database projects table and see how this status are recorded to the table you would see that what is recorded is the key.
So no matter how much stuff you change in the other keys, the data will remain the same, only if you erase that key or change its value you will have a different result.

Pedro A.

[jimmo]

Hola Pedro!

Thanks for the quick response. Actually, it was looking at the project and task tables that led me to the sysvals table, so that part is clear. From a database perspective, there is obviously nothing wrong with having non-sequential values since all you are doing is a lookup. I have many tables of this type on my own site, and there are many gaps in the sequence.

The fact that the sequence itself is stored as single field within the sysvals table is uncommon (in my experience), so it is hard for me to say what effects non-sequencial values have. For example, I save seen code where it started at zero and read until it got a "null" value. So, if there was a gap between 7 and 99, value 8 would return a null value and the loop would stop. I would call this a bug, but it's is possible that such bugs exists in the dotProject code.

[pedroa]

The fact that the sequence itself is stored as single field within the sysvals table is uncommon (in my experience), so it is hard for me to say what effects non-sequencial values have. For example, I save seen code where it started at zero and read until it got a "null" value. So, if there was a gap between 7 and 99, value 8 would return a null value and the loop would stop. I would call this a bug, but it's is possible that such bugs exists in the dotProject code.

The sysval_value has to be seen as a multidimensional array field.
The system gets the whole field and then breaks its data in a
key => value with the | separator between key and value.
Line feed separates its inner records.
About your example, the 8 value (key) is not possible because it was never an option in the first place, or the 8 key and value were deleted from the sysvals, and there are records with this 8 option still.

So the bug here is not the dP system but the admin that was too lazy to check if he could or couln't delete this lookup value because there was still records related in the according tables.

The user will choose what the admin. lets him to, because these lookup values are part of admin modules.

Another hint I give you is to test these things yourself before saying they don't work, and if they don't and you have a solid example to give that is not abstrational but real then lodge them in the Mantis system.

Pedro A.

[jimmo]

Hola Pedro!

Thanks again for your quick response.

You are reading far too much into what I said. I **never** said "they don't work". I said that I have seen code where it loops through and does not find (for example) a value "8" it stops, despite the fact there is a value "9". I would still call that a bug in the code, **if** something like that exists with the dotProject code. However, I never said that I found such a bug nor did I say dotProject "doesn't work".

This does not make sense to me:

About your example, the 8 value (key) is not possible because it was never an option in the first place, or the 8 key and value were deleted from the sysvals, and there are records with this 8 option still.

So the bug here is not the dP system but the admin that was too lazy to check if he could or couln't delete this lookup value because there was still records related in the according tables.


I never said anything about deleting values, I said I wanted to create values, but leave a gap.
Why is "8 value (key) is not possible because it was never an option in the first place". Are you saying there is a limitation to how high these numbers can go? It's fairly obvious that if there was no number 8 in the table it won't appear in the options list on the form. However, if the code fills the array using a loop (i.e "while not null"), there is a problem. If the array is simply filled array[offset]=value, then things are happy.


The user will choose what the admin. lets him to, because these lookup values are part of admin modules.

Another hint I give you is to test these things yourself before saying they don't work, and if they don't and you have a solid example to give that is not abstrational but real then lodge them in the Mantis system.


I **have already** tested it by leaving a gap, but I would prefer not to run the system like that without knowing if the code does something foolish. I could look through all of the code that references the tables in question, but I was hoping that someone would be willing to give me a definitive answer as to whether these gaps would cause a problem. I would prefer spending my time using the product and not looking through code.