[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: [wine]  Re: Implement RegFlushKey
From:       David Lee Lambert <lamber45 () cse ! msu ! edu>
Date:       2003-12-31 13:55:01
Message-ID: Pine.GSO.4.31.0312310744160.5378-100000 () arctic ! cse ! msu ! edu
[Download RAW message or body]

On Sat, 27 Dec 2003, Shachar Shemesh wrote:

> Dmitry Timoshkov wrote:
> >"Shachar Shemesh" <wine-devel@shemesh.biz> 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





[prev in list] [next in list] [prev in thread] [next in thread]