Release 4.7
This document lists all changes for the most recent major release (releases with number X.Y) and subsequent minor releases (with numbers X.Y.Z and perhaps further identifiers), including major and important changes and a list of all user-visible modifications. Change History repeats the list of user-visible modifications for this release and includes similar lists for earlier releases.
The release described in the documentation set is 4.7.
Major Changes in release 4.7
Release 4.7 has, in addition to numerous bug fixes and general enhancements described below, the following new features:
Support has been added for Mongo databases. These can now be opened and queried by AllegroGraph. See Mongo Interface for more information.
X.509 support is available for python clients. See below.
There have been numerous enhancements to the SPARQL implementation. See below.
The changes in the previous major release, version 4.6, are listed just below.
Major Changes in release 4.6
Query processor optimizations for complex SPARQL v1.1 queries.
Improved efficiency of AllegroGraph Warm Standby and Replication.
New Duplicate triple/quad suppression.
New Support for Client Authentication via X.509 certificates.
AGLoad feature and efficiency improvements; see Data Loading.
Non backward-compatible change introduced on v4.4. Since this change from release 4.4 is not backward-compatible, we are repeating it again. Duplicate deletion is no longer done in the background by choosing a deletion strategy. Instead, duplicates are only deleted when delete-duplicate-triples is called (either a direct call to the Lisp function or using one of the APIs).
Changes in earlier releases
This document lists changes in the current release, 4.6 and 4.5. See the Change History for a list of all changes in the earlier releases.
AllegroGraph 4.7 user-visible changes
AllegroGraph Server: General Changes
Rfe11587 - Change InstanceTimeout defaults
The configure-agraph script now supports instance timeouts in interactive mode and via the --instance-timeout
command line option. It defaults to one week.
Also, the default value the InstanceTimeout configuration directive (effective when there is no global or catalog level InstanceTimeout) has been changed from 0 (= disabled) to one hour.
Rfe11536 - Transitive inference queries could be slow
The RDFS++ reasoning for transitive queries could be slower than necessary for some datasets. The code has been reimplemented to be significantly faster.
Rfe11285 - Improve query constraint analysis
AllegroGraph now does a better job of applying filter constraints throughout a query. For example, previous versions of AllegroGraph would not have transformed either of the two BGPs (on either side of UNION) into range queries (which are more efficient).
SELECT * {
?a ex:d ?c .
{ ?a ex:b ?c . } UNION { ?a ex:c ?c . }
FILTER (?c > 2)
}
Now it will.
Bug21114 - Instances lingering too long
Instances with non-zero InstanceTimeout only timed out when there was activity involving the service daemon. This has been corrected. Instances with an InstanceTimeout of zero (the default) are not affected.
Bug21094 - Queries against federations could signal UPI-not-in-string-table errors
It was possible for queries against federated triple-stores to lead to UPI-not-in-string-table errors. This has been corrected.
Bug21089 - agload division by 0
Progress reporting failed with division by 0 if the operation completed within 1ms.
Bug21077 - Expressions can be analyzed too eagerly
It was possible for constant expressions to be analyzed to their final values too quickly which could lead to an error if the expressions were used in a BIND. For example, this query would fail:
select * { bind(str('hello') as ?x }
rather than producing a single binding of ?x
to the string hello
. This has been corrected.
Bug21069 - A warm-standby client now exits non-zero if error occurs during commit replay
Replication secondary (warm-standby client) now exits non-zero if error occurs during commit replay. This is to ensure transactional behavior in the replica.
Bug21059 - Improve efficiency of all predicates cache when RDFS++ is enabled
The query engine keeps track of the predicates in the triple-store to optimize queries which contain clauses where the predicate position is a variable. If RDFS++ was enabled and the cache was not already fresh, then AllegroGraph would try to find all of the store's predicates with reasoning enabled. Since new predicates cannot be inferred, this could be hugely inefficient. This has been corrected.
Bug21057 - Fix log rotation causing crashes
When the SIGHUP handler closes a log stream, attempts to log could fail with a 'stream closed' error potentially crashing the server. This bug has been fixed.
Bug21040 - Turtle data import should use UTF-8 encoding
The Turtle specification mandates that Turtle files are encoded using UTF-8. AllegroGraph was not enforcing this in all cases which could mangle Unicode data on import. This has been corrected.
Bug21022 - Group expressions with unbound elements could be dropped
AllegroGraph could lose rows in a aggregation query if the GROUP BY expression resulted in unbound columns. This has been corrected.
Bug21008 - Correct XSD datatype for certain division operations
When performing division of two xsd:integers or two xsd:decimals, AllegroGraph was emitting the result as an xsd:float rather than an xsd:decimal. This has been corrected.
Bug21007 - Error creating a session with non-default graph for inferred triples
The syntax for starting a reasoning session that uses a different graph for its inferred triples is
<store>[rdfs++#<graph>]
AllegroGraph was failing to parse this specification correctly and signaled an error instead. This has now been corrected.
HTTP Client
Rfe11601 - HTTP and WebView: MongoDB interface config
Added resources to HTTP protocol for MongoDB parameters:
GET /repositories/[name]/mongoParameters
POST /repositories/[name]/mongoParameters
See Mongo Interface, The HTTP Protocol, GET mongoParameters, and POST mongoParameters.
SPARQL
Rfe11558 - Add query logging support
To add in query debugging and tuning, SPARQL queries using the 1.1 query engine can now be logged to the AllegroGraph log file. To log a query, use the prefix option notation by pre-pending this prefix to your query:
prefix franzOption_logQuery: <franz:yes>
The log output will go directly to the AllegroGraph log. In this release, the output is relatively cryptic. Please consult with Franz ([email protected]) to interpret the data.
Rfe11492 - Add support for SPARQL CSV and TSV
Added CSV (comma separated values) and TSV (tab separated values) as native SPARQL output formats. Also corrected problems with using CSV output on result sets with unbound values.
Rfe11486, Rfe11538 - improve SPARQL 1.1 engine geospatial integration
The SPARQL 1.1 query engine did not implement the POINT extension for SPARQL FILTER functions so that queries like:
SELECT * {
...
} ORDER BY geo:haversine-km(?loc,POINT(105.842328, 21.0184040))
would fail. This has been corrected. Additionally, the geospatial query analyzer has been improved so that more computations are carried out at query analysis time rather than at query execution time. This can speed up some geospatial queries tremendously.
Bug21117 - Some SPARQL 1.1 path queries could parse incorrectly
The SPARQL 1.1 parser could combine some combinations of alternation and sequences incorrectly. For example, this query
SELECT ?xxx ?yyy {
?xxx (dc:aaa|dc:bbb/dc:ccc) ?yyy .
}
would have been parsed as if it read (dc:aaa|dc:bbb|dc:ccc). This has been corrected.
Bug21093 - SPARQL UPDATEs could fail to save newly created strings
If run with chunkProcessingAllowed, a SPARQL UPDATE query that generated new strings could fail to save some of these new strings in the underlying triple-store. This has been corrected.
Bug21082 - Optional cross-product with no bindings could fail
If the final step of a query was a LEFT-JOIN and that LEFT-JOIN was also a cross-product (i.e., the right hand side shared no variables with the left hand side) and the right hand side produced no bindings of its own (e.g., it was all constant or its variables could be elided because they were not used anywhere else in the query), then it was possible for AllegroGraph to incorrectly remove answers. This has been corrected.
Bug21078, bug21083 - Handle sub-query SELECT expresions and filters correctly
SELECT expressions in sub-queries were not being handled correctly by AllegroGraph. This has been corrected so that queries like
SELECT ?a (?a * 2 as ?b) ?c ?d {
BIND(1 as ?a)
{ SELECT ?c (2* ?c as ?d) {
BIND(20 as ?c)
} }
}
now perform properly.
It was also possible for AllegroGraph to incorrectly optimize FILTER expressions in sub-queries that returned all variables (*). This too has been corrected.
Bug21072 - unused variable check could remove variables in EXISTS filters
The SPARQL 1.1 query planner removes variables that are not used in the query from the set of bindings maintained during query execution. Unfortunately, the check to see whether or not a variable was used could fail to properly descend into EXISTS (and NOT EXISTS) filters. For example, the following query would have failed:
PREFIX : <http://example/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
SELECT DISTINCT (?s1 AS ?subset) (?s2 AS ?superset)
WHERE
{
?s1 rdf:type :Set .
?s2 rdf:type :Set .
?s1 :member ?x .
FILTER ( ?s1 = ?s2 || NOT EXISTS { ?s2 :member ?x . } )
}
This has been corrected.
Bug21064 - Unneeded graph variables with DISTINCT query could error
If the variable in a GRAPH clause was not needed by the query (because, e.g., the query asks for DISTINCT results and the graph variable is not used anywhere else in the query), then the query planner will remove the variable from the plan. Unfortunately, the query executor could still try to assign a value to the graph variable which would lead to an error at query execution time. This has been corrected.
Bug21046 - Multiple MINUS clauses could lead to query execution error
A SPARQL query with multiple MINUS clauses could cause the SPARQL 1.1 query engine to incorrectly determine the variables on which to join the clauses. For example, this query would fail:
SELECT (?s1 AS ?subset) (?s2 AS ?superset) {
# All pairs of sets
?s2 rdf:type :Set .
?s1 rdf:type :Set .
MINUS {
?s1 rdf:type :Set .
?s2 rdf:type :Set .
# Assumes ?s1 has at least one member
?s1 :member ?x .
# If we want to exclude A as a subset of A.
# This is not perfect as "?s1 = ?s2" is not a
# contents based comparison.
FILTER ( ?s1 = ?s2 || NOT EXISTS { ?s2 :member ?x . } )
}
MINUS {
# If we don't want the empty set being a subset of itself.
?s1 rdf:type :Set .
?s2 rdf:type :Set .
# Choose the pair (empty set, empty set)
FILTER ( NOT EXISTS { ?s1 :member ?y . } )
FILTER ( NOT EXISTS { ?s2 :member ?y . } )
}
}
This has been corrected.
Bug21037 - Construct queries with Turtle results format can cause string lookup error
If a SPARQL CONSTRUCT query used expressions to create strings that were not already in the underlying triple-store and if the RDF format requested with Turtle, then a UPI not in string table error
could be generated. This has been corrected.
Note that the other RDF formats do not exhibit this behavior.
Bug21031 - Remove unstable optimization
The SPARQL 1.1 query engine attempted to reduce the amount of work needed to evaluate certain joins. Unfortunately, it was possible to create queries that exposed a conflict between this optimization and other optimizations which would lead to an error at query evaluation time. This optimization has been temporarily removed. It will be added again once the conflicts it exposed have been resolved.
Bug21023 - Correct datatype of the seconds() function
The SPARQL 1.1 seconds() function should return a value of type xsd:decimal but AllegroGraph was returning xsd:float. This has been corrected.
The date and time functions (like month() and seconds()) were also not behaving correctly on literals of type xsd:time. This has been corrected.
Bug21019 - Filter EXISTS with fixed triple patterns could fail
If a SPARQL query used FILTER (NOT) EXISTS and the EXISTS clause contained fixed triple-patterns, then AllegroGraph could signal an error. For example, this query would fail:
SELECT * {
?a a ex:Fruit .
FILTER EXISTS { ex:apple a ex:Plant . }
}
This has been corrected.
Bug21016 - UPDATE with blank nodes could lead to error
A SPARQL UPDATE query that included blank nodes in the INSERT template could lead to an error. This has been corrected.
Bug20994 - Correct (in)equality test between plain and typed literals
Some comparisons between plain literals and typed literals could return false rather than signaling a SPARQL type error. This meant that a FILTER that tested for (in)equality could succeed where it should have failed. This has been corrected.
Bug20840 - Improve comparisons between xsd:dates and xsd:dateTimes
The SPARQL operator mapping table is quite strict in the sort of comparisons that are allowed. AllegroGraph was allowing inequality comparisons between xsd:dates and xsd:dateTimes even though these datatypes are not strictly comparable. These sort of comparisons will now signal a type error leading FILTER conditions to fail. I.e., a query like
... FILTER ( ?aDate > ?aDateTime ) ...
will now fail (correctly) even though it may have resulted in results previously.
Bug20736 - Federated-triple-stores can fail to find equivalent literals
In SPARQL filters, typed-literal equality is based on the value of the literal, not its lexical form. I.e., these literals are all the same:
- '4'^^xsd:byte
- '4'^^xsd:long
- '4'^^xsd:unsignedByte
To reduce the amount of work during query execution, the SPARQL engine checks to see whether any triples exist with literals of these (encoded) types. This check was being handled incorrectly for federated triple-stores which could lead to answers being left out of federated result sets. This has now been corrected.
Bug20770, Bug21020 - improve SPARQL 1.1 aggregation support
SPARQL 1.1. allows assignment in a GROUP BY clause. For example:
... GROUP BY (str(?name) as ?theName) ...
AllegroGraph did not allow for this syntax and required the work-around of:
... BIND(str(?name) as ?theName) ... } GROUP BY ?theName ...
This omission has been filled.
Secondly, AllegroGraph did not allow aggregate expressions in the HAVING clause or SELECT expression involving more than one aggregate. For example, these queries would fail:
SELECT (avg(?value) as ?avg) ((min(?value) + max(?value)) / 2 as ?half {
...
}
and
SELECT * {
...
}
group by ?value
having(sum(?value) > 20)
Both of these omissions have also been corrected.
Bug20165 - Unnecessary variable in a BIND clause could cause error
If the variable in a BIND clause was not needed by the query (because, e.g., the query asks for DISTINCT results and the variable is not used anywhere else), then the query planner will remove the variable from the plan. Unfortunately, the query executor could still try to assign a value to the variable which would lead to an error at query execution time. This has been corrected.
AGWebView
Rfe11601 - MongoDB interface config
Added support in WebView for setting MongoDB parameters, in the Repository Overview page. See Mongo Interface.
Rfe11557 - WebView: serve doc files
AllegroGraph documentation, a collection of HTML files installed with the server, is now served by WebView, and the Documentation menu in WebView links to these local files in addition to those on www.franz.com.
Rfe11474 - Execute query without changing text
In the Query editor, a query may now be executed without editing the text.
Rfe11398 - Update query editor to CodeMirror v2.24
The query editor for SPARQL and Prolog, implemented by CodeMirror, has been upgraded from v2.15 to v2.24, including javascript and css.
Bug21085 - Webview: Recent queries should not add items redundantly
WebView Recent Queries now keeps the most recently used queries. If a previous query (including the same planner and limit) is repeated, that query is moved to the top of Recent Queries, with the number remaining the same. Limit and planner are displayed on the Recent Queries page.
Bug21062 - Recent queries in multiple browser tabs
Using WebView in multiple tabs of a browser caused a javascript error leading to a blank screen below the menu. This has been fixed by consistently using localStorage.
Note for using multiple browser tabs/windows: the last tab to execute query will overwrite localStorage of "recent queries" that will be seen if a new browser tab is opened.
Bug21050 - WebView: CodeMirror Query editor steals arrow keys
When the cursor is in Query Editor, Alt-LeftArrow and Alt-RightArrow will now perform the default browser behavior instead of navigating within the editor page.
Bug21036 - Editor empty after 40 recent queries
WebView holds up to 40 recent queries, but incorrectly restored the text when more than 40 were made. This is fixed.
Note that logout and login will clear the list of recent queries.
Bug20998 - Webview: failures in IE7
Many links to navigate between WebView pages did not work in Internet Explorer 7 (IE7) due to usage of browser history. In the Query editor page, limit and planner options did not take effect in IE7. These problems have been fixed.
Bug20982 - Query limit and planner selections ignored
In the Query editor screen, the limit and planner selections were ignored. Now, they are both used for Execute and Download. Also, they will remain set after Execute, and following a link from the Recent Queries page will remember these settings for that query (but they are not stored for a Saved Query).
Changes to the Lisp API
Bug21042, Bug21043 - standardize remote-triple-store SPARQL cursors
The cursors returned by run-sparql for remote-triple-store
s behaved differently from ones returned for other triple-store classes. In particular, SELECT queries could not request a results-format of :cursor and the rows returned by cursors were lists of bindings rather than arrays of bindings.
The cursors for remote-triple-store
s are now standardized to behave in the same way as cursors in the rest of AllegroGraph. This item is repeated above under AllegroGraph Server: General Changes, where it is also pointed out this applies to Lisp clients only.
Bug20067 - Make session ping threads more resilient
Remote clients ping their sessions to keep them from timing out on the server. Intermittent network errors could cause the ping thread to fail. This fix makes pinging attempts continue until the session timeout passes without successful pings.
Documentation
Bug21080 - Doc layout bad in IE intranet-mode
AllegroGraph docs now use html5 doctype and style. For Internet Explorer (IE), the highest mode available will be used because IE7 layout is not optimal.
Python Client
Rfe11244: Python Support for client X.509 certificate authentication
To support X.509 certificate authentication with SSL, AllegroGraphServer objects now have cainfo and sslcert keyword arguments for indicating the client security information. verifyhost and verifypeer can also be used.
These arguments correspond to the pycurl.CAINFO, pycurl.SSLCERT, pycurl.SSLVERIFYHOST, and pycurl.SSLVERIFYPEER settings on the Curl object if you want to read about them in the pycurl documentation for more information.
user and password keyword arguments can be omitted when using certificate authentication.
See src2/franz/openrdf/tests/tests.py's test_ssl for example use.
Java Client
Rfe11523 - Upgrade to Sesame 2.6.5 jars
With this change, the Java client has been updated to use the Sesame 2.6.5 jars.
Rfe11358 - Upgrade Clojure to 1.4.0
The Clojure client API now uses Clojure 1.4.0 and Leiningen 1.7.1.
Bug21099: java pool holds sockets open
Problem: the AGConnPool used one MultiThreadedHttpConnectionManager per AGRepositoryConnection, but only closed it with the pool rather than with the repo. This used multiple connections to the main AGraph port and left http socket connections open for them and a session port after the AGRepositoryConnection was closed. Session ports are not recycled by the AGraph server if SessionPorts is not specified.
Fix: use a SimpleHttpConnectionManager for each AGRepositoryConnection and close both at the same time. This minimizes socket connections and avoids the secondary pool within MultiThreadedHttpConnectionManager.
Bug21092 - Clojure: errors in tutorial
Enhanced repo-federation to work without rcon-args as was used in the tutorial. This fixes tutorial example16.
Enhanced value-factory to work with either Repository or RepositoryConnection. This reduces reflection warnings in the tutorial.
AllegroGraph 4.6 user-visible changes
AllegroGraph Server: General Changes
Rfe11449 - Timeout for database instances
Support has been added for making database instances linger for some amount of time after their last close. This allows for reducing the likelihood that a subsequent access to an otherwise idle database will require a long startup time. The time to linger is determined by the global and per catalog InstanceTimeout directive whose default is 0s.
InstanceTimeout is from the instant the last session or backend that has the store open closes it.
New function ensure-not-lingering of the same argument as open-triple-store.
close-triple-store has a new keyword arg :ensure-not-lingering.
Rfe11445 - Queries with large intermediate result sets could generate segfaults
Queries with very large intermediate result sets could generate segmentation faults. This has been corrected.
Rfe11440 - Remove trailing slash from server URL
With this change, AGServer now removes any trailing slash from the specified server URL. Previously, an errant trailing slash on the server URL resulted in an obscure error message about "No suitable response format available" that was difficult to diagnose.
Rfe11418 - improve efficiency of AllegroGraph's turtle parser
Improved the memory usage and speed of AllegroGraph's turtle parser making it more than twice as fast as previous versions.
Rfe11404 - Optimized opening stores
By reducing inter-process communication latency, opening triple stores has been made significantly faster.
Rfe11177 - Agload --relax-syntax flag
agload now uses --relax-syntax flag instead of --relax-for-btc flag. This flag now allows for underscores and dashes to be used in anonymous node strings for N-Triples and N-Quads. agload is documented in Data Loading.
Rfe11126 - SSL client certificate and CRL support
New https-verification keyword argument to open-triple-store and create-triple-store.
Rfe8881 - Optionally suppress duplicates at commit time
AllegroGraph now has a switch duplicate-suppression-strategy, which will prevent new duplicate triples (both duplicates already in the store, and duplicates within the same commit) from being committed to the store.
Bug20997 - Solve latency issue while starting replication.
Fixed a bug where transaction logs (tlogs) were repeatedly (and unnecessarily) examined when performing replication. Now each tlog is examined once. This results in the time required to be O(n) instead of O(n*n) (that is, time is linear with the number of tlogs rather than increasing by the square of the number of tlogs).
Bug20984: Turtle serializer emitted invalid blank node identifiers
The rdf-n3 (turtle) serializer was emitting blank node identifiers without prefixing them with ":_". This has been corrected.
Bug20981 - Exhausted cursor recycling happens too early
Exhausted cursors were being recycled too early which could sometimes result in program crashes. This has been fixed.
Bug20968 - Improve string dictionary cache performance
When heavily used, AllegroGraph's string dictionary cache could become bogged down in bookkeeping resulting in very poor performance. This change prevents this excessive bookkeeping and provides the expected near-constant cache performance.
Bug20943 - Free text index bug under replication
When a new free-text index was created while replication was enabled, it caused an error in the standby process. This is now fixed.
Bug20913: Xsd date and time coercion functions could signal error
If given invalid input, the type coercion functions for dates, times and dateTimes could signal an error other than a SPARQL type error. This would lead to a query error rather than a filter failure. For example, this query:
prefix xsd: <http://www.w3.org/2001/XMLSchema#>
select ?ds ?d {
bind( '2012-12-04 is my favorite day' as ?ds )
bind( xsd:date(?ds) as ?d )
}
would signal an error rather than returning a single result for which the binding for ?d
is empty.
This has been corrected.
Bug20910 - Queries with variable predicates could lose results
If AllegroGraph finds a query pattern with variable predicates and distinct results (and certain other conditions that are data dependent are also true), then it will optimize the pattern by converting it into an iteration over all of the distinct predicates in the store. A typical query of this form is
select distinct ?p {
?s a ex:Animal .
?s ?p ?o
}
Because computing all of the distinct predicates is expensive, AllegroGraph caches this information. Previously, AllegroGraph could fail to update the cache correctly when new triples were added. This could lead to queries returning too few results.
This has been corrected.
Bug20896 - Hang when max chunks for an index reached
As part of their operation, the automatic index optimization processes will sometimes merge some number of input chunks into a single output chunk in order to keep the total chunk count below a certain threshold. However, under some circumstances, some indexes would never undergo the optimization process so this chunk reduction would not occur. Eventually the chunk limit would be reached and the database would hang. This problem has been corrected.
Bug20887 - AllegroGraph XML parsers should not follow external references
AllegroGraph's RDF/XML and TriX parsers could try to follow external references in input files and fail. This has been corrected.
Bug20877 - xs:date could fail on some short plain literals
The xs:date constructor function could fail to correctly create a date if the argument passed to it was a small plain literal. E.g., constructs like
BIND (xsd:date( concat(str(?date), '-01-01')) as ?begin_date)
could pass a string whose length was less than 10 to the xs:date function and this could lead to the failure.
This has been corrected.
Bug20833 - openFederated should handle remote stores
AllegroGraphServer.openFederated now works on remote stores. Previously it always attempted to open supplied arguments as local stores.
The openFederated API still has some limitations. To open a federated session with all federation minilanguage features such as reasoning and graph filtering, pass a properly formatted spec string to AllegroGraphServer.openSession directly.
Bug20822 - Cascading error can occur if database create/open fails
Previously, if there was an error during database open/create, another error could occur during the cleanup process, obscuring the actual problem. This has been fixed.
Bug20819 - problem with some combinations of multiple OPTIONAL clauses
Some query patterns with OPTIONALs whose left-hand side was empty could lead to incorrect results. An example of a query that could have failed was:
select distinct ?value ?type ?name {
OPTIONAL {
?value <http://example.com#isa> ?type .
}
OPTIONAL {
?value <http://example.com#name> ?name .
}
FILTER( REGEX(STR(?name),'Sa') && BOUND(?type) )
}
This has been corrected.
Bug20814 - Make session urls unique
In order to avoid accidental sharing of sessions, include a unique session id in the session-url. Behind the scenes, what previously looked like http://localhost:55555
is now something like: http://localhost:55555/sessions/7e8df8cd-26b8-26e4-4e83-0015588336ea
.
Bug20806 - fix loading of initfile and sitescripts
Initfiles and sitescripts longer than 4096 characters were presented with 4096 character long blocks in reversed order. This bug is now fixed.
Bug20799 - turtle-parser was case sensitive when parsing numbers
AllegroGraph's turtle parser was failing to parse floating point numbers that used an upper-case E
before the exponent. This is now corrected.
Bug20793 - RDFS++ queries with free predicate could infer invalid triples
If a query involving RDFS++ reasoning used an unbound predicate, the reasoner could use inverse property reasoning to infer invalid triples. This has been corrected.
Bug20757 - Problems when starting agraph while another agraph is running
Previously if you tried to start AllegroGraph when it was already running, the second start would fail but it would cause the already-running AllegroGraph to stop operating correctly. This has been fixed.
It has always been acceptable to run two or more AllegroGraph servers simultaneously as long as they, at the very least, used different settings for the following parameters in their configuration files:
Port
SettingsDirectory
GlobalShmServerDirectory (defaults to the value of SettingsDirectory)
The operating system already enforced a unique Port setting. This change adds enforcement of unique SettingsDirectory and GlobalShmServerDirectory settings. Therefore some (dangerous) side-by-side AllegroGraph configurations that used to work may no longer start up. An instructive error message will be displayed in this case.
Bug20628 - Changes to warmstandby API
PUT /repositories/[name]/warmstandby
If one attempts to start a replication task that already exists, an http 409 Conflict response will be returned.
Bug20533 - Agload --rapper flag documentation
The --rapper flag is now specified in the group "Other options". Previously it was not given a group in the command line help. agload is documented in Data Loading.
Bug20508 - Remote triple store can't use the RDFS++ reasoner
Added support for apply-rdfs++-reasoner on a remote client triple-store.
HTTP Client
Rfe10812 - Improve http tracing
HttpTrace is now a global configuration directive of the same meaning as the --http-trace command line option. The global directive HttpTraceOptions and the command line option --http-trace-options were added, the value of which is a comma separated list of options. Options starting with the character + turn on the corresponding log category. Those starting with - turn them off. Use the max-message-size=+log,max-message-size=1000
.
Bug20798 - Improved http error handling
Previously, if the client that was performing an http request died and the backend couldn't transmit the response, then the backend was killed and the request was retried on another backend that also failed because the client socket was closed which wasted resources. The new behavior is to let the backend live on (without retrying), if the error is really from the client side.
SPARQL
Rfe11469: add line number to SPARQL parser error messages
The SPARQL parser will now indicate the line at which an error is encountered. The error message has also been reformatted to make it easier to understand the parsing problem.
Rfe11357 - enhance SPARQL 1.1 engine for changes to standard
The SPARQL 1.1 standards committee recently made several small changes to the standard. To accommodate these, AllegroGraph's SPARQL engine has:
- added support for the functions STRBEFORE, STRAFTER and REPLACE
- removed support for the function SHA224
- relaxed the type validation for REGEX so that language tagged literals and typed literals of type xsd:string can be searched without resorting to the STR function.
- returns rdf:langString as the datatype of a language tagged literal
- accepts solution modifiers for ASK queries
There are several other changes to the standard which AllegroGraph will support in a future release. These include:
- Grammar: Backslash character escapes in prefixed names
- Grammar: Fix: Allow ASK to take solution modifiers
- Grammar: Fix: AdditiveExpression: '?' => '*'
- Allow aggregates in ORDER BY clause
For additional information, please see the SPARQL release notes.
Bug20951 - SPARQL could fail to match plain and typed strings
SPARQL specifies that a plain literal (like "hello") is equivalent to a literal with type xsd:string (like "hello"^^xsd:string). The SPARQL 1.1 query engine was failing to provide this entailment in some cases. This has been corrected.
Bug20939 - CLEAR only recognized if it's the first verb
The SPARQL 1.1 UPDATE verb CLEAR
was only recognized correctly if it was the first verb in a SPARQL statement. This has been corrected.
Bug20936 - OFFSET 0 and LIMIT did not mix
If a SPARQL query used an explicit OFFSET of zero, the LIMIT would be ignored. I.e., a query like:
SELECT * { ?a a ex:Animal . }
LIMIT 10 OFFSET 0
would return all ex:Animals rather than just 10. Leaving the OFFSET off entirely would produce the correct behavior. This has been corrected so that OFFSET 0 is treated as expected.
Bug20912 - Inequality filters could signal an error
Inequality filters in SPARQL queries can be transformed into fast range queries. If a query used a filter like
FILTER( ?a < 0.0 )
then the SPARQL 1.1 query planner could attempt to decrement an unsigned number below zero which would lead to a segmentation fault.
This has been corrected.
Bug20911 - SPARQL could lose precision on very small numbers
SPARQL numeric conversion routines could treat double-floats and decimals as single-floats which would lose precision. For example, a query with a filter like
FILTER( ?x > 4.5e-45 )
would have been interpreted as
FILTER( ?x > 0 )
This has been corrected.
Bug20898 - Complex queries could fail on federated triple-stores
Because of the way statistics were calculated on federated triple-stores, SPARQL queries with many clauses in a basic graph pattern (BGP) could fail when the query engine attempted to re-order them. This has been corrected.
Bug20891 - Improve SPARQL comparator selection
SPARQL specifies difference comparison operations depending on the type of the things being compared. The SPARQL 1.1 query engine could select the wrong operation if both the left and right hand sides were variables. This has been corrected.
Bug20884: improve Lisp client remote-triple-store SPARQL interface
The remote-triple-store implementation of the Lisp client was unable to execute SPARQL queries with non-trivial filter clauses. This has been fixed. (Repeated in the Lisp API section below.)
Bug20867: REPLACE function in SPARQL 1.1 used incorrect syntax for matches
The SPARQL 1.1 REPLACE function was implemented using a different syntax for pattern replacement than that specified by the standard. Replacements are now correctly specified using the $<number>
syntax.
Bug20863 - Some SPARQL XSD numeric computations could fail
Depending on the datatypes of the numbers involved, it was possible for a SPARQL numeric computation to signal a type error rather than correctly returning a value. This has been corrected.
Bug20859 - Some filter combinations could cancel each other out
If a SPARQL query used IN (or several FILTERS like ?uri = constant) and if there were other filters on variables that overlapped with the variables in the IN construct, then it was possible for AllegroGraph to lose track of the additional filters in some circumstances. This happened due to two separate query optimizations handling the filters inconsistently. This problem has been corrected.
Bug20852 - remote-triple-store and SPARQL UPDATE don't mix
The Lisp remote-triple-store client could signal an error after evaluating a SPARQL UPDATE statement. The UPDATE would occur but the result would be mis-interpreted and signal an error. This has been corrected.
Bug20851 - SPARQL FILTERs could be too strict
Certain combinations of triple patterns in a BGP and FILTERs could cause AllegroGraph to misapply the FILTERs. For example, depending on the underlying triple-store, this query
SELECT ?first_film ?actor ?second_film {
?first_film dbpp:starring dbpr:Jack_Black , ?actor .
?second_film dbpp:starring dbpr:Joan_Cusack , ?actor .
FILTER ( ?actor != dbpr:Joan_Cusack )
FILTER ( ?second_film != ?first_film )
FILTER ( ?actor != dbpr:Jack_Black )
}
could have misapplied the ?actor
filter and produced fewer results than expected.
This has been corrected.
Bug20838 - SPARQL CONSTRUCT queries could fail for large result sets
Due to limitations in the internal mechanisms used to keep track of intermediate results, SPARQL CONSTRUCT queries that returned more than 100,000 rows would cause a segmentation fault. This has been corrected.
Bug20830 - Some inequalities could use the wrong comparisons
Some SPARQL 1.1 queries could select the wrong comparison code when comparing two variable clauses with either >=
or <=
. This could lead to incorrect results. This has been fixed.
Bug20821 - EXISTS or NOT EXISTS and additional filters did not mix
The new SPARQL 1.1 EXISTS and NOT EXISTS filters failed to parse correctly when combined with other FILTER clauses. This has been fixed.
Bug20805 - encodeforuri could produce incorrect results
The SPARQL 1.1 encode_for_uri
could produce incorrect results for some UNICODE characters. This has been corrected.
AGWebView
Rfe10885 - Setting duplicate suppression from AGWebView
Added "Suppress duplicate statements" feature to the repository overview page. This sets the duplicate-suppression-strategy switch, which can be set to prevent new duplicate triples (both duplicates already in the store, and duplicates within the same commit) from being committed to the store.
Bug20996 - Webview: js error creating a new repo
This fixes a javascript error when creating a repository from the Catalog page.
Bug20993 - Webview: Internet Explorer (IE) compatibility mode
AGWebView now includes an HTML meta header for IE9 so that IE9 will use its documentMode instead of IE7 compatibility. Also tested with IE8.
Also using html5 doctype to get standards mode in all browsers.
Bug20963 - Fix session url in AGWebView
URLs for sessions are changed in Bug20814 (described under AllegroGraph Server: General Changes above). This fixes AGWebView and changes the url for its use of sessions to include the uuid.
Bug20894 - AGWebView not working with ie9 on intranet
When connecting to AGWebView on an intranet site IE may automatically use Compatibility Mode. A syntax error causes it to only display the "Loading" message and not continue. Work-around is to use a full url, or otherwise not use compatibility mode. The syntax error is now fixed so an intranet does not cause the error.
Bug20843 - AGWebView sometimes clears the editor
The execute button would clear the query editor (and the results area). This happened when the same query had been executed sometime before in the same browser followed by logout/login. The browser history mechanism had not been fully cleared. Recent queries are cleared after logout. This is now fixed.
Changes to the Lisp API
Bug20884: improve Lisp client remote-triple-store SPARQL interface
The remote-triple-store implementation of the Lisp client was unable to execute SPARQL queries with non-trivial filter clauses. This has been fixed. (Repeated in the SPARQL section above.)
Bug20883: improve the Lisp client's remote-triple-store caching interface
The Lisp client's remote-triple-store implementation did not support the spogi-cache-enabled-p
or spogi-cache-size
methods. This has been corrected.
Bug20185 - Remote lisp client used wrong value for restriction reasoning
For a remote reasoning store, this method used the wrong string internally, leading to an error when a query was made:
(setf (restriction-reasoning-enabled-p *db*) t)
For a remote reasoning store, this method enabled restriction reasoning if the key :restriction-reasoning-enabled was present regardless of the key's value. Now respects t or nil.
(apply-rdfs++-reasoner :restriction-reasoning-enabled nil)
Documentation
No significant changes.
Python Client
Rfe11313 - Remove export*, use response capture
RepositoryConnection.export and exportStatements have been deprecated. They used client side serialization of statements that was buggy and not up to spec. The functionality has been replaced with a way to capture server responses of any supported mime type.
A new context manager function on RepositoryConnection is called saveResponse, and can be used as follows:
with open('out', 'w') as response:
with conn.saveResponse(response, 'application/rdf+xml'):
# The server response is written to response
conn.getStatements(None, None, None)
You can reference the function testsaveresponse in src2/franz/openrdf/tests/tests.py for examples.
Java Client
Rfe11493 - Support writing N-Quads from an AGModel
With this change, the Jena adapter now supports writing to N-Quads via AGModel.write(out, "N-QUADS").
Rfe11438 - Provide N-Quads parser/writer META-INF/services in agraph.jar
With this change, the agraph.jar now provides N-Quads implementations for org.openrdf.rio.RDFParserFactory and org.openrdf.rio.RDFWriterFactory in META-INF/services (Sesame doesn't yet provide N-Quads implementations).
Rfe11436 - Add Sesame 2.6.2 src jar
With this change, the openrdf-sesame-2.6.2-onejar-src.jar has been added to eclipse project classpaths (repo and distribution) for convenience.
Rfe11397 - Support RepositoryFactory and Repository configuration
With this change, the Java client now supports Sesame's RepositoryFactory api and Repository configuration from RDF data. See javadoc for the new com.franz.agraph.repository.config package for details.
Rfe11240 - Support user/role management
With this change, AllegroGraph superusers can now dynamically manage users and roles. See the AGServer javadoc for details.
Rfe11230 - Support masquerading as another user
With this change, an AllegroGraph superuser can now masquerade as another user when issuing requests. See the javadoc for AGRepositoryConnection#setMasqueradeAsUser for details.
Bug20946 - IE javascript error in Mold: innerHTML is null
Work-around: the error dialog can be dismissed and the search results are still displayed. Fixed.
Bug20811 - Allow prolog queries from javascript
To run javascript the user must have the "execute arbitrary code" permission which should be enough to run prolog queries too. The bug that was fixed prevented the user from running prolog queries from javascript.
See Change History for user-visible changes to earlier releases.