Right now ids follow a standard auto increment mechanism in the database, this is not optimal as it allows to easily guess ids as well as to easily find out the structure of the database and override what could be protected namespaces; such as in the case of fragments.
Change the type of the id to be a text type, and use random alphanumeric identifiers for the id (no solution comes to mind on how to generate this index).
The second solution proves to be the most flexible as the id type being a string will prove to be incredibly effective as well to allow for custom identifiers to be set, however it would require a major refactor where every single id in every single file would need to be changed to be string/text.
The first would be easier to implement since it would require a simple change to the way the index works as well as how values are created; but it will not allow for custom ids.
I feel like gravitating towards the first because it's easier and for the end user there is no much difference, however this creates a coding situation where numeric values hold some meaning to them; but this is a hurdle to the programmer, we can probably make the first 1000 values to be protected and unable to be held by an index.
Right now ids follow a standard auto increment mechanism in the database, this is not optimal as it allows to easily guess ids as well as to easily find out the structure of the database and override what could be protected namespaces; such as in the case of fragments.
Two solutions come to find.
The second solution proves to be the most flexible as the id type being a string will prove to be incredibly effective as well to allow for custom identifiers to be set, however it would require a major refactor where every single id in every single file would need to be changed to be string/text.
The first would be easier to implement since it would require a simple change to the way the index works as well as how values are created; but it will not allow for custom ids.
I feel like gravitating towards the first because it's easier and for the end user there is no much difference, however this creates a coding situation where numeric values hold some meaning to them; but this is a hurdle to the programmer, we can probably make the first 1000 values to be protected and unable to be held by an index.