Edmond,
Wow! go! go!
Yes, I have worked on something in the past. As has Sander Striker. My
original vtable patch was not accepted. Instead I was asked to break it
up. When I began to do so, I got a little push back as to the validity
of my design. Some work did go in but nothing vtable related. I began
to draft a design document for the pluggable phase.
There is a rough draft of it floating around off list "OK, most likely
in a pile of trash somewhere:-)". I've been pulled in other directions
for some time now, so I don't know how useful it is in it's current
form. CMike seemed cool with it before. It's a Word document. I can
post it somewhere if people want to see it.
I kinda kept it off list so as not to disrupt 1.0 progress with a rather
large and long-term goal. The plan was to convert it to XML and put it
in the pluggable-db branch. I don't have time for that right now.
The original vtable patch is very outdated at this point. However, I
have other work which creates a vtable based abstraction layer for the
DB access itself. In the documents you read it's called the db_vapi.
It's rather involved to explain here. It is a boiled down ODBC/JDBC
type layer. Originally, I wanted ODBC to be the API plugin point for
supporting more than one DB. After some work I decided that it would
not be the correct choice. However, the first, and only working,
adapter is the ODBC adapter. I did work on the Oracle and Mysql
adapter. All of it was based on a very old version of Subversion and
APR. So I need some time to get it working.
I'm in the middle of a "S... storm". The most I can do right now is post
my pluggable document somewhere. BUT Please don't let this conversation
get in the way of 1.0. I use and love Subversion and don't want to see
it veered off course by such a large discussion.
Edmund Horner wrote:
> Hi all.
>
> I've been playing around with replacing the BDB stuff with equivalent
> MySQL stuff, that is, I've:
>
> - Copied the libsvn_fs/bdb directory to libsvn_fs/mysql.
> - Modified the files of libsvn_fs/mysql to use MySQL queries to
> store and retrieve data.
>
> Bear in mind that, although they are currently compiling, things aren't
> *working*. (I had forgotten to do anything with trail.c!)
This is a big omission:-)
>
> 3. Strings: The BDB implementation stores strings as multiple
> records under a single key. I'm not sure if this is necessary
> for an SQL implementation. (Though I currently do the same
> thing, except that each string record has additional 'from'
> and 'to' fields that can be used to find appropriate string
> records for a particular segment of a string.)
There are a number of options here. And with the schema in general.
>
>
> 4. I'm using the InnoDB table type, which provides "transactions".
> I personally haven't had much experience with transactional
> databases, so I don't yet know if it'll be easy to provide the
> same level of ACIDity as BDB has, but I have done some testing.
> That is, I've tested how the 'next-id' record is used by
> concurrent processses, and realised that "FOR UPDATE" must be
> appended to SELECT queries that retrieve the next-id. This
> probably wouldn't be necessary if AUTO_INCREMENTs were used;
> but it might well be necessary for other records.
You shouldn't *have* to use "for update" when auto_increment columns are
being used. Research sequences. As in "Oracle" sequences. There are
tricks for approximating them in MySQL. You can't get all the way
there, but you can get close.
>
>
> 6. I haven't written code to track the memory allocated by the
> MySQL functions yet. And it is possible that a lot more
> memory is being used, since the SQL is generated and stored in
> trail->pool (if the amount is significant I'll look into using
> subpools)
Yes. This was a concern of mine way back. I wanted to develop a
standard set of calls to manage subpools.
I made an initial proposal unrelated to SQL DBs. However, my SQL work
was the motivation for it. It was not received well.
> .
>
> 7. I have read about G. Thompson's fs vtable work (though I
> haven't seen it), and since it sounds like a good thing,
> I've avoided duplicating the effort.
The original patches are on the same site you read those OLD OLD docs at.
>
>
> 8. For the record, I'm also not sure how to translate the BDB error
> macros to elegant MySQL equivalents...
Ah yes, I did some work in this area but can't remember what . Dang, I
need to go flip burgers somewhere!
>
>
> III. The Repository
>
> 9. The MySQL database is stored outside the repository, and accessed
> through sockets using the MySQL client library. Where should the
> MySQL configuation data (hostname, username, password, database)
> by stored, and what should be stored in place of the BDB data?
> (Currently the MySQL data is stored in fs.c!) I'm inclined to
> keeping the code to recognise a MySQL or BDB repository, and
> creating/opening/etc'ing the database, in libsvn_fs.
This is yet another major conversation. I had problems with the Hash
arguments being passed to the FS. I want to use svn_config_t. I know
some config work has been done for svnserve. I haven't looked at it
though. I'm completely out-of-date in this area. My SQL work uses them
in a BIG way. In fact I need two methods added to svn_config_t as I recall.
I will post my document on a web site "as-is" if the commiters don't
have a problem with it.
As for 1.0. GREAT WORK GUYS!
Where can I send money for the 1.0 bar tab?
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 19 17:08:04 2004