OK - I'll go ahead as time permits.
[[
The process might be a bit intermittent depending on the network
connectivity while travelling. I'm going into the office this coming
week ... which in my case involves UK->US.
]]
Andy
On 29/04/16 21:08, Dave Reynolds wrote:
+1
Dave
On 29/04/16 17:45, A. Soroka wrote:
+1 from this non-committer to holding the cache work for now. A simple
on-off switch seems absolutely requisite, and preferably we would have
fine-grained controls. The sudden appearance of an always-on cache
like this would represent really surprising new behavior for
integrators. Also, from the discussion on the PR in question [1] it
seems to me that there are still some questions of design.
[1] https://github.com/apache/jena/pull/95
---
A. Soroka
The University of Virginia Library
On Apr 29, 2016, at 12:38 PM, Andy Seaborne <[email protected]> wrote:
I'd like to go ahead with 3.1.0.
The work on a query cache for Fuseki [*] was tested by Osma and found
to be useful. There was also feedback on configuration and bounding
the resources consumed by the caches. Without the ability to
configure it (including turn it off) I don't think that putting it in
right before a release is a good idea. There are is still some
discussion to be had about the detailed design goals.
So what I suggest is release Jena 3.1.0 now as-is, and start a
testing/evaluation phase for a configurable cache.
As a cache is most important under load, and Fuseki is used in
deployed and public facing systems, I'm concerned that we block
people picking up all the other things in 3.1.0. I think it would be
good to get wider testing via users@. That will take time. (And then
if people don't test it until after its in a release ... well, we can
only do our best.)
Andy
[*]
https://issues.apache.org/jira/browse/JENA-626
https://github.com/apache/jena/pull/95
On 18/04/16 12:35, Osma Suominen wrote:
Hi Andy!
I'm happy with the current state of Jena and would support a release.
This time I've been more diligent in using recent snapshots so there
should be less chance of problems that surface only around release
time.
I have no outstanding work that I want to do for jena-text currently.
JENA-1134/AnalyzingQueryParser (which you can consider including in the
release notes) was the major item for me since the previous release,
plus some bugfixes that were done earlier.
-Osma
On 18/04/16 13:44, Andy Seaborne wrote:
Version 3.1.0 has quite a few good things in it1
I think it is about time we released it.
So this is a first ping for anything you want to get done for it.
As for timing - I can RM it sometime in the next few weeks though it
will have to fit around other things.
Andy
-------------------------------------------
* New custom functions and aggregate functions
Added:
+ afn:sprintf (contribution from Alessandro Seganti)
+ The XQuery/XPath Functions and Operators "math:" functions
+ Custom aggregates for stdev etc. (also STDEV etc as keywords).
* RC features in 3.0.1:
+ In-memory transactional dataset (Adam Soroka )
+ SPARQL extension for CONSTRUCT Quads (Qihong Lin)
* OSGi fixes (Jaroslav Pullmann)
* Upgrades:
jsonld-java : 2.8.2
jackson 2.6.3
slf4j 1.7.20
dexx collections 0.2 -> 0.6 (OSGi)
* DatasetGraphs & transactions
* New module jena-cmds
* Logging - log4j marked <optional>
* Fuseki: Multiple service per file, shared datasets
* JSON result fix type: "literal" not "type": "typed-literal"
* Space saving when parsing (FactoryRDF)
Parsing RDF now saves space by partial interning RDFTerms
created during a each parser run.
