Hi Mike,
I have to agree with you - I guess the best way to go will be to have
anew field as unique id (autoincrement) to be used as primary key - the
way the AVPs are defined makes very complicated to get a reasonable
primary key based on data itself.
adding the ID column will not affect the DB structure since this new
column is not to be used by the avpops module, so no version or other
changes are required. Just in table definition at mysql level.
so, I'm for changing it before the release.
regards,
bogdan
Mike Williams wrote:
I agree.
I think that each table should use a single key, preferably an
auto-incremented integer that has no relation to the data in the table.
Requirements always change, and having a key unrelated to data insulates
against that. Additionally, having compound primary keys (keys that are made
from two or more columns) complicates ORM greatly. This is something I have
run into in developing my own interface.
However, I understand the difficulty in changing the database layout now. I'm
sure some of the fundamental changes I would like to see would require much
additional coding effort throughout OpenSER, which I shouldn't start asking
for until I'm able to help with coding.
I would be willing to share some of my views on the database structure, and to
help design an upgraded layout if any of the developers felt like it was
needed and/or important at this time.
---Mike
I note that user_preferences has uuid as start of the primary key - up to
version 1.0.1 the username was the key.
Surely I dont like to cause any offence with the developers - but wouldnt
it be preferable to have consistent key indexes across all modules for
similar functionality ? It appears that only the avpops module utilises
the uuid lookup.
I came across this due to the serweb problems which can either use username
or uuid as key index but not both.
Cheers
Gerry
_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
