+1 for option 1
On Sun, May 26, 2013 at 8:33 PM, Stephen Owens <[email protected] > wrote: > 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 > -- I like: Like Like - The likeliest place on the web<http://like-like.xenei.com> Identity: https://www.identify.nu/[email protected] LinkedIn: http://www.linkedin.com/in/claudewarren
