2012/12/10 Jesse Glick <jgl...@cloudbees.com>
> On 12/08/2012 01:11 PM, Kohsuke Kawaguchi wrote:
>
>> Map is by definition single index, so I'm not sure it works for many
>> typical use cases. Say test reports—we need to be able to
>>
>> query all failing ones for a given build as well as all the past
>> executions of a specific test case.
>>
>
> What is stopping you from creating several maps, corresponding to the
> indices you care about for this plugin?
>
Pretty soon you'll be writing a miniture database engine. I don't mean
disrespect for mapDB, but I don't think it eliminates the benefits of SQL
RDBMS. For example, in the two indices use case I mentioned, "all tests of
this specific name" index wouldn't be too easy to maintain with MapDB,
because this needs to be constantly updated.
RDBMS may be trading the efficiency with ease of development, which I think
is often a valid trade-off.
At certain point, I think the argument would become "you don't have to use
it if you don't want it." I still think RDBMS addition is a reasonable
feature for things like test reports and coverages. I mean, it's just a
matter of time before someone writes it, even if we don't, no? And adding
RDBMS support won't preclude anyone from using mapDB, too.
But if we really want to create an use-case specific efficient storage, it
seems to me that the write-only skip list like structure would be really
useful. The model is that the key is Map<String,String> and the value is
arbitrary length binary stream, and it'll support look up via a subset of
keys.
So we'd store lots of records like
{build=15,class=Foo,package=org.acme,test=testMe}->testRecord, and we can
look this up with {build=15} to look for all tests in build, or
{class=Foo,package=org.acme} to see all the tests in the org.acme.Foo class
in the past, etc.
This can be "easily" done by maintaining a write-only data storage with
linked list for each prop=value in keys.
I see no advantage in nontrivial SQL queries for Jenkins, since the reason
> to have SQL be able to perform queries beyond looking up the value for an
> indexed key is to offload processing from the client to the DB server to
> avoid excessive network traffic. For an embedded DB this is a nonissue: you
> can write whatever predicates/filtering/sorting/**grouping/etc. you want
> in Java code (and more easily and flexibly).
>
> Supporting user-defined queries seems vastly less important than having
> efficient and compact data storage. And as far as familiarity of API is
> concerned, MapDB is much simpler than JDBC; anyway the audience for this
> API is a few people writing plugins such as JaCoCo.
>
--
Kohsuke Kawaguchi
