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
