Seems like a good alternative if it lowers the support cost enough that it doesn't take much to release it. It might bring an interested maintainer out of the woodwork if they don't want to see SDB support reduced further or vanish.
On Sat, May 25, 2013 at 6:18 AM, Andy Seaborne <[email protected]> wrote: > 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 >>>>> >>>> >>> >> >> >> > -- Regards, * * *Stephen Owens* CTO, ThoughtWire t 647.351.9473 ext.104 I m 416.697.3466
