Re: [jgit-dev] JDBC based storage layer for JGit

[Shawn Pearce <spearce@xxxxxxxxxxx>]

On Tue, Feb 22, 2011 at 06:24, Thun, Philipp <philipp.thun@xxxxxxx> wrote:
> You are too fast for me to keep pace ;-) I was actually working on an enhanced version of my first prototype and already implemented most of your feedback. Seems I am working too slow...

Sorry about that. :-(

I should have waited longer and let you work on it. But it was really
nagging me yesterday, so I decided to see how much work it really was
to do something reasonable for JDBC too. FWIW, Amazon S3 is also
nagging me, but its because I haven't solved how to deal with the 1.4
million tiny ObjectIndexTable records for the Linux kernel, or the
hundreds of tiny RefTable records. These two are almost better
candidates for the SimpleDB product than they are for the S3 product.
(And maybe that is the answer?)

> Nevertheless I learned a lot by implementing this stuff and especially your feedback. I will now have a look at your Gerrit change and see whether I can help.

My code is a lot less tested than yours. I didn't get as far as having
a daemon setup and storing JGit within a SQL server. To be honest, I'm
getting tired of creating the CassandraDaemon, HbaseDaemon, etc.
classes. We should be able to generalize these pgm tools better.

I'm starting to think we should use a META-INF/services file that can
register a GitDirHandler implementation, where GitDirHandler can get
the String --git-dir command line argument and either resolve that
into a Repository, or into a RepositoryResolver (for the daemon
argument of what to export). Then each DHT spi can just register this
GitDirHandler through its own META-INF/services file and the standard
pgm bundle will just work correctly on the command line.

I'm happy to stop work on this if you want to pick up from this new change.

I know someone wanted to use Git within a SQL database so that ref
updates could be part of a larger transaction that also updated other
records in the database. Unfortunately the way I've used JDBC here
within the Client and ClientPool classes, the embedding application
doesn't get to control the JDBC transaction that we are making updates
in. I'm not sure how to easily support that usage model (where the
application loans us a connection and we have to stay within its
transaction without committing), and the more general DHT spi model
where a lot of work is done on background threads using quickly
loaned-returned connections.

-- 
Shawn.