Looking back at the code again.. it does use the Jena Node and Resource
clases so it is Jena specific.

It could build an ARQ syntax tree -- I just didn't go that far with it.

I think there is a need for a Commons and have created jena-commons in the
Experimental branch.  Currently that only contains the Apache commons
Configuration implementation that uses Models to store the configuration
options.

I could add this there.

I don't have a handle on git structure so I won't comment on that, but will
read and learn.

Claude


On Tue, Jul 22, 2014 at 1:33 PM, Andy Seaborne <[email protected]> wrote:

>
>
>
>
> On 21/07/14 20:34, Claude Warren wrote:
>
>> I have code for a query builder that I would like to contribute... but I
>> don't see a good place to put the code.
>>
>> It is not Jena specific.
>>
>
> So it's string based?
>
> Can it (could it) build an ARQ syntax tree?  That avoid the need to parse,
> and makes it harder to have injection issues (accidental or not so
> accidental).
>
>
>
>> it has the following methods
>>
>> addFilter()
>> addGraph()
>> addOptional()
>> addOrderBy()
>> addPrefix()
>> addSubQuery()
>> addUnion()
>> addVar()
>> addWhere()
>> build()
>> clone()
>>
>> the build() method creates a SELECT statement string.
>>
>> the clone() makes a deep copy so it is easy to create a base query in code
>> and then extend it.
>>
>> Anybody have any idea if and where it might go in the Jena source? Perhaps
>> the jena-commons experimental code?
>>
>
> Let's think this through for the general case.  The question must be how
> this fits into releases.  Separate release?  In conjunction with the main
> release?  If it's just source code hosting (no releases), github may be a
> better choice.  Releases have a special status.
>
> It's also most as if "we" (the wider community inc users) would benefit
> from something like Apache Commons.  What else might be a candidate for
> such a thing?
>
> How might we structure the things so that the design works for git as well?
>
> One possibility is that there is a number of different areas "trunk",
> "commons"(or some such area like "modules", "main", ...)
>
> But git will clone everything unlike svn that can pick and choose (isthat
> correct for git these days?)
>
> What I think we need to have a clear setup as to what's in the main
> releases and what's an additional area so that people don't get the
> expectation that an additional module is going to get released every main
> release.
>
>
>
>> If we decide that it doesn't belong, I'll just create a git hub project
>> for
>> it.
>>
>> Claude
>>
>>
> WDYT?
>
>         Andy
>
>
>


-- 
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren

Reply via email to