On Sat, 27 Dec 2003, Shachar Shemesh wrote: > Dmitry Timoshkov wrote: > >"Shachar Shemesh" <[EMAIL PROTECTED]> wrote: > > > >>This is a request to understand, not a suggestion (yet?). > >>Why not use a general purpose DB system? (postgresql, mysql, whatever) > >>After all, the registry is just a tree shaped database. We can do that > >>using standard SQL, and fall back to our current method if a proper DB > >>is not found. ... > Two tables - one for keys, one for values. > > The keys table: > key ID, primary key (serial type in PGsql). > Key name, varchar (or whatever). > Parent key (foreign key to key ID). > unique index on key name (if the database support the collation where > things are case insensitive, which most databases should).
This should be UNIQUE(parent_id,key_name), unless the "Key Name" is actually the full path, which seems counterproductive. > The values table: > Key - foreign key to the Key ID in the keys table > Value name, varchar. > Value type - long int > Value data - binary > Primary index - key+value name (unique). > > Alternatively, if you want easier editing of the DB itself, you can > split the data into seperate tables - one for strings, one for numbers, > and one for everything else. As you point out, this would require triggers or database-specific constraints to maintain integrity. (Actually, you could probably make this into one table; aren't key names and value names in the same namespace? - No, they're not. Win32 has seperate functions RegEnumKey() and RegEnumValue(). On WinME, it's possible to have a subkey and a value by the same name.) > What you gain - fast, efficient, Unicode aware manipulation. Data > integrity taken care for you. Concurrancy taken care for you. Seems too > good to be true, I think. One thing to think about is performance. Do we want to undergo round-trip network time for every call to RegOpenKey()? Now, with prepared statements and a binary database protocol ofer a UNIX-domain socket the overhead might not be so bad, but it's still an extra layer. The real power of this is that it would allow for better multi-user interaction, if that's what is desired. Wine could load HKEY_LOCAL_MACHINE based on $HOST or $DISPLAY and HKEY_CURRENT_USER based on getuid(), all in the same table. I'm not sure how secure this would be, since most SQL databases don't support row-lovel ownership of data. (Perhaps we could change to a three-tier approach, in which registry keys are exposed as XML objects?) Global search-and-replace is easy in SQL: just do an "UPDATE table SET x=REPLACE(x,'pattern','new value') WHERE x LIKE '%pattern%'", for instance. To do regular-expression substitution of all keys recursively under a certain one, one might need to write a one-page perl script, but an ASCII file doesn't preserve the registry's tree stucture either when doing search-and-replace either. -- DLL
