Yes - I'm conflicted as well, flip-flopping between opt1 and opt3.
There is enough user@ traffic to suggest it's used. I'm guessing it's
the "SQL" part makes it easier in corp IT. TDB is faster, scales better
and is better supported (and I'm not corp IT bound).
There are ways to improve it's performance - pushing some filters into
SQL for example - so theres scoep for development.
Option 1 - add to the main distribution, remove if it becomes a block -
means that there is no additional work on a release vote.
Testing SDB using Derby only (that's what the junit does by default) is
easy to setup because it's pulled in by maven. It only runs embedded,
not as a server but it does check the code generation. Unliek other
jjava SQL DBs, Derby implements tree join plans (the other onyl do
linear join plans which makes some optional cases impossible - the code
fall back to brute-force-and-ignorance in these cases). Derby is quite
picky about it's SQL 92. SDB tests without additional setup.
We state on users@ this is the position as a indication that we stil
have option 3 (retirement) available. Unless we shake the tree a bit,
Proposal: (option 1)
add to apache-jena, remove at the first sign of trouble.
make a clear statement of situation on users@ including
encouraging people to come forward
option 3 still on the cards.
I've added DISCUSS to the subject line for now to leave open the
possibility of a vote because it affects the whole project.
But all PMC chipping in here is enough.
I don't see a rush to make a choice just yet.
Andy
On 22/05/13 11:47, Claude Warren wrote:
I am conflicted about this one. I think we need SDB (or something similar)
that will allow users to use standard infrastructure (shared/pooled DB is
fairly common). But I don't have the bandwidth to support it.
Is there a status where in we release SDB package with each release of Jena
but only ensure that the current test cases work -- that is the latest
release doesn't break something? Perhaps with a reduced set of supported
DBs (perhaps Derby & MySQL)
If not then I think we take Andy's approach and release one more before
putting it on the shelf.
On Wed, May 22, 2013 at 10:35 AM, Charles Li <[email protected]>wrote:
What are alternatives to SDB? I have a 4GB RDF/XML to load for later
queries
Thanks!
- Charles
On May 21, 2013, at 12:00 PM, Stephen Owens <[email protected]>
wrote:
+1 for option 3 if no one currently is taking ownership of that project.
I think it's a useful signal to potential adopters about what they should
expect.
On 2013-05-21, at 12:47 PM, Andy Seaborne <[email protected]> wrote:
SDB is getting some user attention but not much developer attention. I
was hoping that there would be a contribution to go with JENA-447 but
nothing has come in. I don't have the bandwidth to even answer questions
about it properly, partly because I don't use it. I guess others are in a
similar position.
I do think we should be clear as to it's status.
In the future, I see these options:
1/ Add jena-sdb to the main distribution.
(If it becomes a block on a release, remove it.)
2/ As is - release "sometimes".
3/ Dormant SDB.
This is the last release unless some activity arises to maintain it.
Keep the source around but move out of trunk.
Can be built from source.
4/ Legacy SDB.
More definite statement than (3) that it is dropped.
Keep the source around.
For 3 and 4, where there are no plans to release again if nothing
changes, the snapshot builds should be stopped. Users can build from
source if they want to but the current snapshot should not become a
distribution-under-the-radar which I feel it becomes if there are no plans
to make it a formal release.
Thoughts?
I'm tending towards doing this one last release then (3).
Andy
