jclouds-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Gaul <notificati...@github.com>
Subject Re: [jclouds-labs] [JCLOUDS-1046] Remove h2-jdbc provider from source tree (#236)
Date Wed, 24 Feb 2016 08:24:51 GMT
I have been looking at the H2-JDBC provider and made several fixes 7b3c8788caa17df47fc914aec4f42af0111257ca,
7255d73ced667002d59985df8a371509989c958c, and d169a7bb7186473ed6f794311b507b4b4975ffeb.  We
have one remaining test failure which appears to be some kind of schema creation issue when
running the first test.

Addressing the broader question of whether this provider has utility, I believe using JDBC
holds promise as other object stores like Swift use SQLite for its metadata and the filesystem
for its data.  Our current filesystem provider has poor performance for list operations due
to the way it emulates a key-value store and does not support metadata on Mac OS X, one of
the most popular testing environments.  The JDBC provider addresses these issues although
the implementation seems clunky to me.  Using JPA is a big hammer for the handful of queries
we execute against likely only a single provider.  We should probably use a database per blobstore
container instead of mixing all the container and blob data in a single database.  Storing
blob data in the database is likely not the best solution.  I have not completely audited
the code but we have several redundant queries, inefficient ETag calculation, and resource
handling leaks.

In all, the current JDBC provider does not seem like the best path forward and I would prefer
something simpler and H2 and JDBC-based instead of JPA.  However, it mostly works and could
help users of S3Proxy on Mac OS X have a more complete experience than the filesystem provider.
 We seem unlikely to replace JDBC in the near future so I would prefer to keep it unless it
causes further issues.  I would also point out that other providers like filesystem had big
problems and took years of hacking to arrive at our current useful state.

Reply to this email directly or view it on GitHub:
View raw message