Table of Contents

Release 4.14

Major Changes in release 4.14

Major Changes in release 4.13.2

Major Changes in release 4.13.1

Major Changes in release 4.13

Major Changes in release 4.12.2

Major Changes in release 4.12/4.12.1

Changes in this and some earlier releases

AllegroGraph 4.14 user-visible changes

AllegroGraph Server: General Changes

HTTP Client



Changes to the Lisp API



Python Client

Java Client

AllegroGraph 4.13.2 user-visible changes

AllegroGraph 4.13.1 user-visible changes

AllegroGraph Server: General Changes

AllegroGraph 4.13 user-visible changes

AllegroGraph Server: General Changes

HTTP Client



Changes to the Lisp API



Python Client

Java Client

AllegroGraph 4.12.2 user-visible changes

AllegroGraph Server: General Changes

HTTP Client



Changes to the Lisp API



Python Client

Java Client

AllegroGraph 4.12 user-visible changes

AllegroGraph Server: General Changes

HTTP Client



Changes to the Lisp API



Python Client

Java Client

Release 4.14

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.14.

Major Changes in release 4.14

Version 4.14 has fixes and enhancements in the following areas:

Major Changes in release 4.13.2

Version 4.13.2 is a maintenance release which supplies an updated OpenSSL library containing a fix for the OpenSSL Heartbleed bug. Other than the availability of Top Braid Composer version 4.4 and 4.4.1 (noted just below), there are no other changes from version 4.13.1. Because AllegroGraph uses OpenSSL, the Heartbleed OpenSSL bug can introduce a security leak. See this Allegro CL Tech Corner article at for links to information about the bug. The end of that article describes how to update earlier versions of AllegroGraph to fix the Heartbleed bug. If you have version 4.13.2 installed, the update described in that article is not necessary as the relevant libraries are already updated in version 4.13.2.

Major Changes in release 4.13.1

Version 4.13.1 is a maintenance release which fixes a bug having to do with index optimization which was revealed after the release of version 4.13. That is the only change in this release compared to version 4.13.

Major Changes in release 4.13

Version 4.13 has fixes and enhancements in the following areas:

Major Changes in release 4.12.2

Release 4.12.2 is in part maintenance release, providing fixes and enhancements, but also includes the following significant changes:

Major Changes in release 4.12/4.12.1

The 4.12.1 release provided a fix to a startup problem experienced by some 4.12 users. It contained no other changes. The 4.12 release includes many bug fixes and incremental improvements and also

Changes in this and some earlier releases

This document lists changes in the current release and several previous releases. See the Change History for a list of all changes in earlier releases.

AllegroGraph 4.14 user-visible changes

AllegroGraph Server: General Changes

Rfe13144 - Add bulk mode switch to agmaterialize command line tool

agmaterialize now supports a --bulk command-line option. If specified, then materialization will be run in bulk mode. This mode provides approximately 30% faster materialization. Note that bulk mode is global to the store and means that transactions will not be durable (in particular, will not be logged). Therefore, the switch should generally be used only when the store is not being used for other operations. See the Materializer document for information on agmaterialize.

Rfe13116 - Audit events for AGWebView login, logout, timeout

With this change, if auditing is enabled, then logIn, logOut, logOutWithTimeout events are added to the audit log whenever a user logs in, logs out, or when a login session times out. See Auditing.

Rfe13108 - Allow restricting superuser access to triples data

This change adds a new global configuration directive: SuperUserCanAccessAllData. If it is enabled (the default), then users with the Superuser permission will have read/write access to all repositories (just like in previous AllegroGraph versions). If it is turned off, then the superuser needs to be granted access to repositories. This is most useful when auditing is enabled and any change to user permissions is logged, as superusers will be able to grant themselves any permissions they want and auditing must be enabled if the fact that a superuser granted him/herself permission is to be recorded.

Rfe13104 - Notify admin by email of user account status changes

This change adds three new global configuration directives: SMTPHost, AdminEmail, and AdminEmailSMTPHost. With SMTPHost one can associate login, password, port, etc with a server:

SMTPHost gmail \  
  server="", ssl=true, starttls=false,\  
  from="", login="", \  

If AdminEmail is defined, then emails for user account status changes events are sent to it:


If there are multiple SMTPHost definitions, then one can explicitly select one of them:

AdminEmailSMTPHost gmail 

See the documentation in Security Implementation for more information.

Rfe13094 - Add EvalAllowed configuration directive

This change introduces the EvalAllowed global configuration directive. If it is yes (the default), then the "Evaluate arbitrary code" permission bits are effective. If it is no, then arbitrary code evaluation is disabled for all users (including superusers), regardless of the value of a user's actual "Evaluate arbitrary code" permission. Configuration directives are described in Server Configuration and Control.

Rfe13091 - Password and account expiration, suspending, disabling

This change introduces a number of parameters to control passwords and accounts. All are described in Server Configuration and Control. The new options are:

PasswordExpiry: The time since the last password change after  
which the password will be expired. One cannot login with an  
expired password, it can only be used to change the password.  
PasswordExpiryGrace: The time since password expiry after which  
the account is disabled. Only the administrator can reenable  
accounts. This option does not affect users with superuser  
MaxFailedLogins: The number of failed logins in a row after which  
the account is suspended.  
AccountUnsuspendTimeout: The time after which suspended accounts  
are unsuspended.  
AccountExpiry: The time since the last authenticated activity of a  
user after which the account is deleted. This option does not  
affect users with superuser permission. 

Rfe13058 - Control password complexity

This change adds four new global configuration directives: PasswordMinLength, PasswordMinUppercaseChars, PasswordMinDigitChars, PasswordMinSpecialChars to allow the administrator to specify password complexity thresholds. All are described in Server Configuration and Control.

Rfe12941 - Allow use of more than 64GiB of query memory

Previously, the start address of the heap holding the query data structures has been such that when the heap grew beyond 64GiB it was likely to collide with shared libraries mapped there which made allocations fail. This change moves the heap so that collision is less likely and much larger heaps are possible.

Rfe12929 - Add changePassword audit event

With this change, when a user's password is changed and auditing is enabled, an audit event of type <> is logged.

Rfe12915 - Improve reporting of shared memory allocation errors

Previously, if allocation of shared memory used by processes serving a database instance failed, the error message was an opaque 'end-of-file'. With this change, the error message expicitly mentions the allocation failure.

Rfe12884 - Include failed login attempts in the audit log

With this change, when auditing is enabled, a failedLogin event is written to the audit log on authentication failures.

Rfe12848 - Removal of query temporary files

Sometimes queries write intermediate results to disk when they will not fit in memory, for instance with an ORDER BY query. If a query failed, some of its temporary files were not removed in a timely manner. With this change, temporary files are always deleted whether the query finishes or fails.

Bug22527 - Sorting UPI maps

Previously, on certain filesystems sorting of UPI maps could fail, which broke the repository instance. The only indication of this bug was the log message "Sort command failed". This bug has been fixed.

Bug22507 - Include id of deleted user in audit report

Previously, the audit report did not include the user id of the affected user associated with deleteUser events. This bug has been fixed.

Bug22466 - Setting geospatial type mappings did not register the subtype

Previously, setting a geospatial datatype or predicate mapping did not also add the geospatial subtype to the triple-store. This has been corrected.

Bug22465 - In the turtle format, QNames are a superset of XML QNames

AllegroGraph's turtle parser required QNames (like rdf:type) to be XML QNames but the turtle standard approved in February 2014 allows additional flexibility. In particular, the first character of the local part of a QName may start with a digit. Previously, a QName like rdfs:0 would have signaled a parse error. Now, it will be accepted.

Bug22450 - RDF/XML serializer could re-use node abbreviations

For efficiency, the RDF/XML and RDF-N3 serializers maintain a mapping from URI to prefix abbreviation (e.g., from to rdf:type). It was possible for the map to become corrupted during serialization leading to different nodes being printed as if they were the same. This has been corrected.

Bug22422 - Federated triple-stores cannot use geospatial magic properties

The check for whether or not a triple-store could use a geospatial magic property was too stringent. This has been corrected so that federated triple-stores can be queried with geospatial magic properties. Note that every store in the federation must agree on any geospatial predicate type mappings used in the query. If they do not, then an error will be signaled during query planning.

Bug22371 - Fix race condition when using free-text indices.

Previously, a race condition existed where a client A would fetch the list of free-text indices on a repository, but have the set of indices modified by a client B, thus rendering client A's list out of sync. This could result in unexpected errors in certain situations, such as when opening repositories. Now, attaching to free-text indices is synchronized so that this race condition is avoided.

Bug22363 - Fix log rotation

A bug was introduced in v4.13 where a SIGHUP sent to the Service Daemon would not cause the log file to be closed and reopened. This is now fixed.

Bug22345 - Use customer namespaces in remote clients

Similar to rfe12679 (under SPARQL below), AllegroGraph now uses customer namespaces when serializing output in RDF/XML for all clients. Previously, temporary namespaces were used.

Bug22319 - Materializer not inferring rdfs:subClassOf reflexivity

The materializer was not always correctly inferring that classes were rdfs:subClasses of themselves. This has been corrected. This change also improves the performance of AllegroGraph's OWL 2 RL materializer significantly.

Bug22300 - Fix error when system time is in the past

Previously, if the system time in the environment of deployment was before the build time of the AllegroGraph, then queries would fail with an error saying:

Attempt to do an array operation on nil which is not an array. 

This bug has been fixed.

Bug22297: ensure-not-lingering should latch

Previously, if a request to delinger a store could not be honored because it was still in use by another process, the request would be ignored. Now, the request is deferred until the store is no longer in use.

Bug22293 - Make agraph-backup support dynamic catalogs.

Previously, backup and restore operations would fail when operating on repositories in dynamic catalogs. Backup operations were unable to locate the main directory of the repository. Restore operations were unable to locate the main directory of dynamic catalogs.

Now, backup and restore operations support repositories created in dynamic catalogs. They follow the same rules as other repositories, most notably that when performing a restore operation, all dynamic catalogs must already have been created, or the restore will fail.

See Catalog definitions in Server Configuration for a description of dynamic catalogs.

Bug22259 - Ensure proper transaction log stream alignment on restart

Previously, under certain unusual circumstances, the transaction log stream could be left in a state that prevented a database from reopening properly. This has been fixed.

Bug22243 - Less fragmentation in the shared memory

With this change, the shared memory allocator is more aggressive about coalescing freed regions which reduces the tendency of shared memory to fragment.

Bug22229 - Geospatial type mappings could cause duplicate triples

If a triple-store registered a predicate and a datatype geospatial type mapping that applied to the same triple, then that triple would be added to the store twice. This has been corrected.

Bug22228 - Rare error when opening a triple store

Under extremely rare circumstances, opening a triple store could result in the following error:

The assertion (integerp failed. 

This has been fixed.

Bug22226 - More efficient memory usage

With this fix, the query engine does a more thorough job of giving freed memory back to the operating system which enables more efficient operation under high concurrency workloads.

Bug22211 - Trix parser did not treat Return (ASCII 13) as whitespace

The TriX parser was not treating Return characters (ASCII 13) as whitespace which sometimes led to parse errors. This has been corrected.

Bug22208 - Concurrent queries in shared backends

When the system is under load, a shared backend may execute several queries concurently. Under rare circumstances, the queries involved could change each other's query options and produce incorrect results. This bug has been fixed.

Bug22198 - Listing freetext indices should not error for federated triple-stores

Previously, federate-triple-stores would signal an error when asked to list their freetext indices. They now return an empty list.

Bug22141 - Attempt to close instance during agraph-backup --supersede restore operations.

Previously, using agraph-backup to restore into an open triple-stores would fail. Now, when the --supersede option is specified, such restores can succeed. agraph-backup is described in Backup and Restore.

HTTP Client

Rfe12963 - SERVICE URIs with query strings

Previously, AllegroGraph dropped the query string in a SERVICE URI when making a request. In this example:


the 'apikey' was not sent to the remote web server. This has been fixed.

Rfe12952 - Add global configuration directive UseMainPortForSessions

Normally, HTTP requests to a dedicated session go directly to the process serving that particular session. This has low overhead, but it can make firewall management more difficult because more ports have to be open. With this change, the new UseMainPortForSessions directive may be enabled in the configuration file which makes all communication be proxied through the front-end. Previously, similar functionality existed only in the Java client controlled by the UseMainPortForSessions property.

Rfe12798: Implement repo-specific scripts

The existing scripting HTTP API (sitescripts) manages scripts that can be used with any repository. An HTTP API has been added for managing scripts that are local to a given repository, called "reposcripts". Reposcripts can only be loaded and run against the repository under which the script was loaded. See Scripting the server in HTTP Protocol for more information.

Bug22524 - HTTP protocol should not send partial responses

Previously, queries that used Chunk-at-a-Time (CaaT) processing over the HTTP REST interface would begin streaming results back as soon as the first chunk was processed. If a query timeout was in effect, this meant that AllegroGraph could issue a 200 (OK) response and then only send back only a partial response body. To prevent this, AllegroGraph now computes the entire query result before sending any HTTP response when there is a time out active.

Bug22476 - Unauthorized response for javascript eval

Previously, if the user had no eval permission, attempts to execute javascript failed with HTTP status 400 and a "MALFORMED PROGRAM" message. With this change, the coreect HTTP status 401 'unauthorized' is returned.

Bug22445 - Don't percent-decode path component of HTTP requests twice.

Previously, path components of HTTP requests sent to AllegroGraph were sometimes being percent-decoded twice. For example, the URI


could be seen by AG as either




depending on the URI being requested. This bug isn't likely to have been encountered unless you were attempting to include special characters in repository or catalog names. It is now fixed. Users with applications that make direct HTTP requests should check their request URIs to ensure that they do not double-percent-encode any path components, as these may stop working or have unexpected behavior. Percent-decoding of URI query arguments is not affected.

Bug22369 - Fix server-side javascript http-request property values.

Previously, the property values of javascript http-request objects (method, url, body, etc.) could raise errors due to returning invalid objects. This bug has been fixed, and return values should match what is described in the documentation.

Bug22329 - Fix handling of HTTP 'Expect: 100-Continue'

Previously, AllegroGraph did not send the '100 Continue' response to requests with 'Expect: 100-Continue' headers when the request was forwarded internally to another component. This happened, for instance, when a request to a shared backend or a dedicated session was forwarded via the frontend and also when a requested made directly to a dedicated session was forwarded to the frontend. With this change, '100 Continue' is sent as appropriate.


Rfe13029 - Use POST instead of GET for remote SPARQL queries

AllegroGraph now uses HTTP POST requests instead of HTTP GET requests when talking to remote SPARQL endpoints. This allows for larger query strings to be sent.

Rfe13028: Improve use of partial results when making SERVICE queries

AllegroGraph now makes more use of partially computed results when making federated SPARQL queries using the SERVICE clause. This results in more efficient queries against SPARQL endpoints.

Rfe12911 - Improve estimates for magic geospatial properties

AllegroGraph's size estimates for geospatial queries that use SPARQL magic properties are now more accurate. This improves query clause reordering and can greatly improve query performance.

Rfe12891 - Improve efficiency of some SPARQL geospatial queries

Some queries that use SPARQL magic properties to use AllegroGraph's geospatial engine will now operate more efficiently.

Rfe12822 - Add temporaryFileDiskSpace query option

Sometimes queries write intermediate results to disk when they will not fit in memory, for instance with an ORDER BY query. With a huge query it is possible for a such temporary files to fill the filesystem. In order to prevent this, the temporaryFileDiskSpace query option may be set. For example:

PREFIX franzOption_temporaryFileDiskSpace: <franz:10G> 

As with all query options, it is also possible to change the default value globally in the AllegroGraph configuration file. For example:

QueryOption temporaryFileDiskSpace=10G 

The default is to have no limit. Query options are described here in the SPARQL Reference; the AllegroGraph configuration file is described in Server Configuration.

Rfe12788 - Raise error for invalid use of SPARQL geospatial functions

AllegroGraph now signals an error at parse time when a geospatial function is used with a predicate that is not associated with a geospatial type-mapping.

Rfe12750: SPARQL Property Path cache improvements

SPARQL Property Path computations use a cache to improve the efficiency of transitive closure calculations. The data structures for this cache have been rewritten to be more memory and time efficient. Secondly, the heuristic that the query engine uses to determine whether or not the cache should be aggressively or lazily filled have been improved.

Rfe12284 - Signal an error if a SPARQL GEO pattern uses a constant object or graph place

The SPARQL GEO Clause uses its first pattern to link with AllegroGraph's geospatial system. The object place of this pattern must be left unbound. Previously, AllegroGraph would silently return no results when the place was bound. Now, it will signal an error. For example, the following query would have previously run but returned incorrect results but now it will signal an error.

prefix s: <>  
select distinct ?event ?coord ?date ?platform ?EventType {  
  GEO SUBTYPE s:1.0  
  BOUNDINGBOX( POINT(-084,34), POINT(-082,36)) {  
    # this is an error because the first clause is the one  
    # that connects the query with AllegroGraph's geospatial  
    # sub-system  
    ?event a <http://UCore-SL-Taxonomy-OWL-DL#ObservationEvent> .  
    ?event mo:hasGeospatialCoordinate ?coord .  
  WHERE { }  

Rfe12240 - Improve bound variable analysis when using magic properties

The SPARQL 1.1 query planner now recognizes that variables set via assignment using the BIND clause can be treated as bound when determining whether or not a magic property can be used. This means that queries like

select ?event ?coord {  
  bind(44.30 as ?xMin) .  
  bind(33.40 as ?yMax) .  
  (?event ?coord) franzGeo:inBoundingBoxXY (swp:startLatLong ?xMin 44.50 33.30 ?yMax)  

can now be used.

Rfe11880 - Improve handling of some SPARQL GRAPH clauses

AllegroGraph's analysis of when and how it can execute SPARQL GRAPH clauses has been improved. Depending the query, this enhancement can speed execution by a factor of 10 or more.

Rfe10132 - Improve performance of find unique values for a column queries

SPARQL queries that ask for the DISTINCT values of a particular column are now sometimes significantly faster. Previously, they performed linearly in the size of the triple-store; now, they perform linearly in the size of the number of values returned. In particular, for stores with a small number of predicates or graphs (relative to the size of the store), queries like these will be much, much faster:

SELECT DISTINCT ?p { ?s ?p ?o }  
SELECT DISTINCT ?g { graph ?g { ?s ?p ?o } }  
SELECT DISTINCT ?class { ?s a ?class } 

Note that aggregate queries still require a full-scan of the store, so a query like:

SELECT ?p (count(1) as ?pCount) {  
  ?s ?p ?o .  

will still be expensive.

Bug22529 - Improve use of intermediate information during query

AllegroGraph's set based SPARQL 1.1 query engine sometimes used an intermediate result set when it would have been more efficient to compute the solutions directly. This has been corrected.

Bug22535 - Improve handling of multiple range filters on the same variable

AllegroGraph now handles queries with multiple range filters more efficiently. For example, a query like

select * {  
  ?s ex:test ?age .  
  filter( ( ?age >= 10 && ?age <= 20 ) ||  
          ( ?age >= 60 && ?age <= 70 ))  

will now execute as the combination of two range queries rather than a single scan.

Bug22485 - Improve pattern size estimation logic

AllegroGraph's estimation of the size of triple-patterns in a BGP has been improved. This in turn improves the automatic BGP re-ordering and leads to better query plans when using the statistical clauseReorderer.

Bug22430 - Cross products with unbound variables could lose results

Depending on the query algebra and the order in which clauses were evaluated, it was possible for AllegroGraph to lose some solutions with unbound variables when computing a cross product. This has been corrected.

Bug22391 - Make SPARQL rand() results more independent

Due to an unintended sharing of random number generator state, SPARQL rand() calls in queries running on the same backend can be produce the same stream of pseudo random numbers.

Bug22389 - The chunkProcessingMemory query option could not be specified in a query

The chunkProcessingMemory could only be set using the AllegroGraph config file rather than being able to also specify it in using the PREFIX notation in a SPARQL query. This has been corrected.

Bug22480 - Range queries could cause other filters to be ignored

If a query had multiple FILTERs that applied to a single pattern and one of these FILTERs created a range query, then it was possible for the other FILTERs to be ignored. This has been corrected.

Bug22372 - SPARQL JSON results format was using literal-typed instead of typed-literal

The SPARQL JSON results serializer was emitting literals that had an associated datatype as

"name" : {"type":"literal-typed", "datatype":" D ", "value":" S "} 

rather than

"name" : {"type":"typed-literal", "datatype":" D ", "value":" S "} 

This has been corrected.

Bug22348: EXISTS and NOT EXISTS FILTERs could fail

If an EXISTS or NOT EXISTS FILTER used variables from the outer query in a FILTER (rather than a BGP), then too many solutions could be returned. E.g., a query like:

PREFIX : <>  
SELECT ?x ?n WHERE {  
  ?x :p ?n  
    ?x :q ?m .  
    FILTER(?n = ?m)  

uses the bindings for ?n in the NOT EXISTS FILTER and ?n is not one of the variables that the NOT EXISTS FILTER binds itself. Previously, AllegroGraph will leave ?n unbound and therefore return too many results. This has been corrected.

Bug22336 - Allow the use of magic properties in more situations

The SPARQL 1.1 query planner ensures that a magic property can only be used when all of its required variables are bound. Previously, however, the test for bound variables was overly strict and did not, for example, take BIND or VALUES into account. This has been corrected. For example, this query would previously have been disallowed:

prefix sna: <>  
prefix pred: <>  
prefix : <http://ex#>  
select * {  
  values ?start { <> }  
  ?graph sna:nodalNeighbors (:graphSubClass ?start) .  

because AllegroGraph would not have seen that ?start is bound by the VALUES clause. Now this query will function as expected.

Bug22347 - Query options were sometimes ignored in SPARQL update commands

Previously, AllegroGraph PREFIX options were ignored during the WHERE clause of a SPARQL DELETE/INSERT/WHERE command. This has been corrected.

Bug22321 - Use other sets more in many more cases

The set-based SPARQL query engine now makes better use of partially computed result-sets during query execution. This can greatly accelerate many queries.

Bug22272 - Correct unbound variable handling in MINUS

In rare circumstances variables that were unbound in the right-hand side of a SPARQL MINUS clause could be incorrectly matched with bound variables on the left hand side. This has been corrected.

Bug22270 - Correct BGP estimation for predicates not in the store

If a query clause had either a fixed subject or object and a predicate that was not in the triple-store, then AllegroGraph's statistical estimator could return a positive number rather than zero. This has been corrected.

Bug22253 - Combining reorderDuringExecution and Property Path queries could lose filters

Under rare circumstances, the query engine could lose track of FILTERS in queries that used SPARQL Property Paths and the AllegroGraph reorderDuringExecution option. This has been corrected.

Bug22246 - Catch argument count mistakes in query functions

SPARQL queries that contained functions being called with an incorrect number of arguments would silently fail. These errors are now detected and reported at query time. For example, a query like:

prefix gf: <>  
select * {  
  bind( gf:cartesianDistance(1, 2, 3, 4) as ?b )  
would have previously returned a single unbound result because the  
`cartesianDistance` function should only be given two arguments. Now,  
AllegroGraph will signal an error. 

Bug21941 - Magic properties could lose track of FILTERs

In rare circumstances a query that used magic properties and FILTER on some of the variables in the properties could incorrectly filter out too many solutions. This has been corrected.


Rfe13159 - Enhance AGWebView query GUI

AGWebView's SPARQL query user interface now supports query log viewing, query plan inspection and reports additional details about query execution such as query time and warnings. The HTTP REST API for query has a new parameter, returnQueryMetadata. If supplied and true, then the HTTP response will include a JSON payload containing information about the query in an HTTP header named x-query-info. The revised query page is described here.

Rfe13103 - Reposcripts added to AGWebView

Access to the new Reposcripts API has been added to AGWebView (see the Rfe12798 release notes entry, which has links to other documentation).

Rfe13068 - Login timeout for AGWebView

The new global configuration directive LoginTimeout controls the expiry of inactive AGWebView login sessions. See the description of that option in Server Configuration and Control for the details.

Rfe12925 - Only run AGWebView queries when the Execute button is pushed

Previously, AGWebView executed recent and saved queries as soon as they were selected. Now AGWebView only executes queries when the execute button is clicked.

Rfe12579 - Allow users to change their own passwords

This change introduces the PasswordChangeAllowed global configuration directive. If it is yes (the default), then users can change their own passwords via AGWebView. This is a change in default behavior (there was no facility to allow users to change their own passwords in earlier releases). If you set the value of the option to no, the old behavior will be restored. Configuration directives are described in Server Configuration and Control. User passwords are described in Security.

Rfe12275 - Add query cancellation interface to AGWebView's query pane

In addition to the existing job canceling screen, AGWebView now provides query cancellation directly from the SPARQL query interface. The revised query page is described here.

Bug22536 - Simple queries may not show up in the jobs list

Previously, simple queries like

select  { ?s ?p ?o . filter( fn(?o) ) } 

could fail to appear on the query jobs list in AGWebView. AllegroGraph now checks for query timeout more often which means that even these queries will appear and be cancelable.

Bug22260 - Fix AGWebView audit log date range

Previously, when the start date or the end date was specified in the audit log query (at /#audit), then the query failed with a type error. This bug has been fixed.

Bug20820 - AGWebView's multi-core data import could not specify a graph

When using multi-core loading, AGWebView was incorrectly formatting the graph it sent to AllegroGraph's parallel data import tool. This meant that it was impossible to specify a graph. This has been corrected.

Changes to the Lisp API

Rfe12862 - Extend Lisp geospatial functions with subject, object and graph arguments

Add s, o and g arguments to the Lisp API geospatial functions:

The new arguments act as additional filters on the triples returned by the functions. g can only be used when the use-g argument is nil and o can only be used when the use-g argument is non-nil.

Rfe12830 - Warn when a query has constants that are not in the store

In the Lisp API, the fourth return value of run-sparql now contains information about any warning that occurred during query planning and execution. This includes a warning when a query contains a constant that is not in the store. For example:

select * { ?s <ex://#notHere> ?o } 

would generate a warning regarding <ex://#notHere>. Additional warnings will be added in the future.

Bug22322 - remote-triple-store does not honor default-prefixes argument to run-sparql

The default-prefixes argument to the Lisp run-sparql function was being ignored for remote-triple-stores. This has been corrected.

Bug22225 - Memory corruption in the Lisp direct client

Previously, if an unclosed database object became garbage, memory corruption could occur which lead to unpredictable errors such as segmentation faults under extremely rare circumstances.

Bug22167 - Fix flaws in delete-duplicate-triples.

delete-duplicate-triples is documented as preserving the triple with the lowest possible triple-id from a group of duplicate triples. Flaws in the algorithm used to delete duplicate triples made it possible that the triple preserved would not necessarily have the lowest possible triple-id, and could depend on the order in which the duplicates were sorted. This change corrects that problem.


Bug22179 - Allow safe Prolog query requests in shared backends

Previously, AllegroGraph only allowed Prolog queries when a user had eval privileges for the store. Now, eval privileges are required only for Prolog queries that make use of functors that escape to Lisp.


No significant changes.

Python Client

No significant changes.

Java Client

Rfe12952 - Update Java client for handling of useMainPortForSessions

When the server configuration option UseMainPortForSessions is enabled, all requests to sessions are multiplexed through the frontend port. In this case, the Java system property useMainPortForSession is redundant and its value is not consulted. This means that one can turn on this feature on the client if it's not enabled in the server config, but cannot turn it off.

Bug22392 - Hang with useMainPortForSessions

Previously, when the Java client's useMainPortForSessions feature was enabled, a request returning a large response could hang. This bug has been fixed.

Bug22323 - Fix UseMainPortForSessions when using SSL

Previously, when the com.franz.agraph.http.useMainPortForSessions property was set to true, the Java client arranged for all communication with a session be funneled through the front-end. This fix makes this feature work with SSL connections. Also, with this change it is required that SSLPort is set in the configuration file, otherwise using SSL connections to dedicated sessions with fail.

AllegroGraph 4.13.2 user-visible changes

The only change was to replace the SSL library with one that avoided the heartbleed bug.

AllegroGraph 4.13.1 user-visible changes

AllegroGraph Server: General Changes

Bug22255 - Concurrent full index optimization requests

Previously, if index optimization was requested with a full index optimization already in progress, the database instance would log an error and hang. This bug has been fixed.

AllegroGraph 4.13 user-visible changes

AllegroGraph Server: General Changes

Rfe12645 - Add a command line interface to AllegroGraph's materializer

AllegroGraph now includes a command line tool to materialize the inferred triples in a triple-store. The tool is named agmaterialize. It can currently be run only on the same machine where the AllegroGraph server is running. The command line interface is described in the Materializer documentation.

Rfe12642: Improve handling of datafile free space information

Previously, datafile free space information was maintained in a fixed sized data structure which could run out of room after a certain level of datafile fragmentation was reached. This has been corrected.

Rfe12590 - Shared backend scheduling improvements

Previously, when all shared backends were busy, further requests were held until a backend became available. Such pending requests were scheduled for execution in basically random order with latency up to 1s.

With this change, pending requests are scheduled rather than essentially random. The scheduling is basically FIFO (first in, first out, meaning the oldest request is processed first), but FIFO may be violated for efficiency reasons. (Strict FIFO behavior is undesirable, because it greatly reduces AllegroGraph's ability to schedule requests optimally under stress.)

Also with this change, scheduling latency is now minuscule and shared backends are now allowed to execute slightly more queries in parallel if all backends are busy, which allows greater efficiency in most cases.

Rfe9523 - Logging improvements

This change adds a centralized logging facility to the AllegroGraph daemon. The new logger guarantees no interleaving of messages and is able to deal with full filesystem conditions gracefully. Lisp direct clients have now the option of sending log messages to an AllegroGraph server with the with-log-routed-to-server macro. See the documentation for more. Previously, log messages were sent to the AllegroGraph server belonging to the first direct connection opened in the client.

Bug22220 - Race condition while determining last written transaction log id

Previously, a rare error could be encountered when starting replication or while switching roles, indicating that replication failed due to a missing transaction log that had not yet been written to disk. This problem has been fixed. Now, only transaction logs on disk are used to start replication.

Bug22184 - Instance shutdown and replication

In rare circumstances, when the instance belonging to a replicated repository was shut down, writing the transaction log could fail. This bug has been fixed.

Bug22156 - date-string-to-upi doesn't handle zero time zones consistently

The date-string-to-upi functor was not treating a Zulu time zone specified as "Z" consistently with the rest of AllegroGraph's date and time parsers. This has been corrected.

Bug22111 - Database names may not contain special characters

Because it is impossible to reliably use databases (also called repositories) in session specifications if their names contained characters that are used in those specifications, the list of characters which must not be used in names has been expanded. The following characters are now disallowed in database (repository) names:

\ / ~ : Space $ { } < > * + [ ] | 

Previously, only the following four characters were disallowed in database (repository) names:

\ ~ / : 

Note that this change only effects new databases (repositories); existing databases (repositories) with any of the newly invalid characters in their names will continue to be accessible. It may, however, result in difficulties when attempting to use them in more complex session specifications.

Bug22100 - More strict, faster parsing of some xsd datetimes

The parsers for xsd:date, xsd:dateTime and xsd:time used to be lenient and accept things like:

20131118         # missing separator  
2013-11-18T12:27 # missing seconds 

and many other convenient but non-standard formats. The new parser only accepts what the XML Schema specification mandates which also allows it to be faster. See XSD Date and Time datatypes for more information on these datatypes.

Bug22086 - Materializer deletes triples with the same subject, predicate and object

The initial version of AllegroGraph's materializer deleted all triples with the same subject, predicate and object. This limitation has now been lifted: the materializer now only deletes triples with matching subject, predicate, object and graph.

Bug22032 - Control whether or not external references are followed during RDF/XML import

Previously, AllegroGraph ignored external references in RDF/XML source files. The Lisp API now includes a new keyword argument to load-rdf/xml:

agload also has a new command-line switch. Supplying either of -x or --external-references will cause agload to follow external references. See Data Loading.

Bug21953 - Allow import of triples to reasoning-triple-store

A bug was introduced in v4.12 that prevented import of triples via load-* routines (e.g. load-rdf/xml) on reasoning-triple-stores, when the source argument was passed a URI. This problem has been fixed. This change also provides a better error message when attempting to import statements to a federated-triple-store, which is not allowed.

Bug21656 - Cleaner daemon shutdown

When the AllegroGraph daemon was stopped, despite the claim of doing a 'clean shutdown' in agraph.log, the shutdown of the instances was not clean and the corresponding repositories would potentially require crash recovery the next time they were opened. Also, such a shutdown lost any index optimization work performed since the most recent checkpoint.

With this change, instance processes perform a checkpoint if necessary which makes shutdown slower, but startup faster and it makes sure the index optimization results persist.

Bug20773 - Support federations of RDFS++ stores

Previously, queries against a federation of RDFS++ stores would cause an error during query planning. This has been corrected.

HTTP Client

Rfe12763 - Update HTTP API for the materializer

The REST API for materializeEntailed now includes an inferredGraph argument that can be used to specify which graph newly entailed triples are added to (or deleted from). The materializer is described in Materializer.


Rfe12767 - Improved the efficiency of single group aggregate queries

The code generated for single group aggregate queries is now slightly more efficient.

Rfe12762 - Optimizing level 2 index optimization

With this change, level 2 index optimization (the default) no longer tries to optimize access for triples added since optimization was started. This allows index optimization to finish even if triples are added continuously at a high rate. The new code is faster on average, has the same worst case disk usage (about two times the original size), but it has a higher average disk usage.

Rfe12760 - Improve efficiency of some SPARQL Property Path queries

AllegroGraph now builds some property path data structures as needed rather than computing all of them up front. Depending on the data, this can greatly enhance the efficiency of some queries.

Rfe12757 - Improve efficiency of some property path queries

In some circumstances, AllegroGraph could choose the less efficient of two strategies when evaluating a property path query. AllegroGraph now ensures that it makes the better choice.

Rfe12717 - Handle RDFterm-equality of strings consistently

Previously, AllegroGraph implemented sameTerm() using a strict interpretation of RDF literal equality when comparing plain literals and typed literal strings but implemented = using a more relaxed interpretation. These tests are now done consistently using the relaxed interpretation. In particular,

'hello' is RDFterm-equal to 'hello'^^xsd:string 

This is in accordance with both common usage and the RDF 1.1 specification.

Rfe12699 - Improve efficiency of SPARQL equality tests on resources

The efficiency of equivalency tests in SPARQL filter expressions has been improved.

Rfe12681 - Optimize interprocess communication

The performance of message passing between different AllegroGraph server processes has been slightly improved.

Rfe12679 - Use query local namespace abbreviations in result serialization

AllegroGraph now uses the namespaces defined by a SPARQL query's prefixes when serializing output in RDF/XML. Previously, temporary namespaces were used instead.

Rfe12670 - Allow /SPARQL access to AllegroGraph as a SPARQL endpoint

Previously, access to an AllegroGraph triple-store as a SPARQL endpoint was via sending a query to


This REST API has been augmented so that sending a query to the triple-store's URL with a trailing /sparql also works. E.g.,


This is not required by the SPARQL standard but is in conformance with many other existing endpoints.

Rfe12657 - More efficient handling for the VALUES clause

AllegrGraph now rearranges queries so that VALUES clauses are evaluated first when possible. This improves query efficiency as VALUES clauses are generally small.

Rfe12656 - Improve execution of some nested joins

AllegroGraph now evaluates nested joins more efficiently.

Rfe12498 - Improve full-scan warning heuristics

AllegroGraph warns when a SPARQL query executes a full-scan. Heretofore, this meant that a query like

select * { ?s ?p ?o } limit 100 

could have produced a full-scan warning even though it is benign. AllegroGraph now saves its warnings for when they may actually indicate a problem with the query.

Rfe11981 - New query option chunkProcessingMemory

Previously when chunk-at-a-time processing was enabled (see query option chunkProcessingAllowed), the query option chunkProcessingSize controlled memory consumption by limiting the number of intermediate results stored in memory. The total memory consumption depended on the number of variables and the complexity of the query, so it was rather difficult to know how much a query will actually use. With this change, chunkProcessingSize is deprecated and chunkProcessingMemory can be specified instead. The unit of chunkProcessingMemory is a byte but the usual abbreviations are also accepted ("8G" (the default), "2M").

Rfe11515 - Fully support the SPARQL 1.1 HTTP Protocol

AllegroGraph now fully supports the five different HTTP request types specified in the SPARQL 1.1 HTTP Protocol. These are:

In addition, AllegroGraph continues to support SPARQL update using POST where the update command is encoded in the query portion of the HTTP request.

Bug22350 - Distinct queries could produce duplicate results in rare cases

Under rare circumstances it was possible for the query engine to produce duplicate results when using chunk-at-a-time (CaaT) processing. This has been corrected.

Bug22214 - Encoded IDs failed to compare properly in SPARQL queries

Inequality comparisons between encoded IDs were always returning true. This has been corrected.

Bug22204 - decimal to decimal cast loses precision

When in a SPARQL query an xsd:decimal was cast to xsd:decimal it lost precision as it was converted to a single float internally. This bug has been fixed.

Bug22203 - Fix decimal parsing in SPARQL queries

In SPARQL query strings, decimals in the (-1,0) interval were parsed with the wrong sign. For example, -0.9 was parsed as 0.9. This bug has been fixed.

Bug22153 - Some wild card property path queries could generate incorrect paths

In rare circumstances, the data structures used to cache property path information could be invalidated leading to too many path results. This has been corrected.

Bug22147 - Add support for ObjectId's in the _id field.

The SPARQL MongoDB magic predicate now works with documents containing ObjectId's in the _id field.

Bug22142 - Expressions on aggregates fail for empty group

If a query wrapped an aggregate with an expression like

select (xsd:float(avg(?age)) as ?avgAge) ... 

and the result set contained an empty group (i.e., a group with no members), then AllegroGraph would signal error. This has been corrected.

Bug22134 - SPARQL aggregates on expressions with errors could compute incorrect results

Other than COUNT, a SPARQL aggregate on an expression should return unbound if that expression evaluates to a type error during computation. AllegroGraph was incorrectly returning the aggregate of any bindings produced after the last type error. This has been corrected.

As an example, if AllegroGraph needed to compute the MIN( ?p * 2 ) and ?p was bound to 4, 7, 15, "hello", 6, and 1, then AllegroGraph would previously have returned 2 (the minimum of 12 and 2). Now, it will return no binding for that expressions.

Bug22123: Empty construct template will cause an error

If a SPARQL CONSTRUCT had an empty template like

CONSTRUCT {} WHERE { ?s a ?o } 

then AllegroGraph would signal an error. This has been corrected.

Bug22094 - Correct sparql< and sparql> for date and dateTime comparisons

Because there is no defined operator mapping for inequality comparisons between xsd:date and xsd:dateTime, comparing them should throw a SPARQL type-error. AllegroGraph was incorrectly returning nil instead. This has been corrected. See XSD Date and Time datatypes for more information on these datatypes.

Bug22074 - DELETE templates with unknown variables caused an error

AllegroGraph would signal an error if a SPARQL DELETE/WHERE command's DELETE clause contained variables that were not bound by the WHERE clause. This has been corrected. An example of such a command would be:

DELETE { graph ?unknownGraph { ?s ?p ?o } }  
WHERE { ?s ?p ?o }  

Bug21561 - Remote-triple-stores do not support the table results format

Remote-triple-stores did not support returning tables from SPARQL queries. This has been corrected.


Bug22161 - Adding security filters in Firefox

Previously, with Firefox, clicking the 'add' button in the security filters table of the user management page (Admin/users in the menu) of AGWebView did not submit the form. This bug has been fixed.

Changes to the Lisp API

Rfe12632: Improvements in Lisp API to AllegroGraph materializer

Materialization previously occurred only for triples in the default-graph of the triple-store. It now occurs for all of the graphs in the store. Materialization on subsets of the graphs can be accomplished by creating a graph-filtered triple-store and calling materialize-entailed-triples on it.

Materialization previously placed inferred triples into a special graph that could not be utilized by the rest of AllegroGraph (the special graph behaved similarly to but not exactly like the usual AllegroGraph default-graph). It now places inferred triples into a graph that can be specified in the call to materialize-triples using the materialized-graph argument. It defaults to .

Two new arguments were added to delete-materialized-triples. These are:

Materialization now logs its start and end to the AllegroGraph log file. The overall efficiently of the materializer has also been improved.

Bug22132 - calling run-sparql with the :with-variable argument with a timezoned upi

When the Lisp function run-sparql was used in conjunction with a :with-variable argument that bound a variable to an encoded xsd:dateTime or xsd:time, then in some cases comparisons involving that variable failed to match equivalent representations of the same xsd:dateTime or xsd:time with a different timezone. This bug has been fixed.


Bug22171: Select0 should return UPIs when it can

Previously, the Prolog select0 query macro could return future-parts rather than UPIs. For example, this query would return a future-part.

(select0 (?a) (= ?a !rdf:type)) 

This could cause problems in the unlikely event that namespace abbreviations changed when running the same query multiple times. select0 now returns UPIs so that the above behavior is not possible. Note that if a future-part represents a triple that is not currently in the triple-store, then a query can return UPIs that cannot be printed (because the UPI will not be in the string dictionary).

Bug22157 - Temporal functors could signal an error when used with all bound values

Previously, AllegroGraph used real numbers to represent times, dates and dateTimes. Now, the internal representation includes time-zone information which means that comparing two values can no longer use simple inequalities. The Prolog temporal functors like point-before-datetime had not been updated to reflect these changes. This oversight has been corrected. This change means that the Prolog functors will use the same XSD logic used by the SPARQL date and time functions.


No significant changes.

Python Client

No significant changes.

Java Client

No significant changes.

AllegroGraph 4.12.2 user-visible changes

AllegroGraph Server: General Changes

Rfe12734 - More aggressive level 2 index optimization

In some cases, level 2 index optimization (the default) left a small part of the index unoptimized. With this change, the entire index is optimized in all cases.

Rfe12726 - Index optimization increasing database size on disk

Space in some garbage on-disk data structures is now reclaimed in a more timely manner which makes the increase in database size during index optimization less severe.

Rfe12725 - Faster level 2 index optimization

Level 2 index optimization (which is the default level) has been made faster.

Rfe12636 - Make config-file argument to agraph-backup backup-settings optional.

Previously, the agraph-backup backup-settings command required a config-file argument. This argument has been eliminated in favor of an optional --config option that can be used in place of the --port argument. If both --port and --config are supplied, then the port argument takes precedence. Also, agraph-backup could fail in the past if there were discrepencies between a --port argument specified on the command line, and a Port directive contained in a config file. Now, if the --port argument is specified, it will take precedence over any Port directives read from a config file. See Backup and Restore.

Rfe12635 - Major revision to agraph-backup operating modes.

The various backup and restore modes of agraph-backup have been overhauled.

Previously, backup mode created an archive file containing only repository data. Now, it creates an archive directory that contains both repository data and settings. This archive can be restored via restore or restore-all. The --ext-backup-command option is supported. Previously, restore mode operated on an archive file. Now, it can also operate on an archive directory created by backup or backup-all. In either case, it will restore a single repository (data and settings) from the archive.

The layout of archive directories created by backup-all are slightly changed, and support for the --ext-backup-command option is added. The restore-all mode will now fail if repositories being restored to already exist. Use the --supersede option to force an overwrite of any such repositories.

Previously, the backup-settings mode created an archive containing both repository and system settings. It also supported the --ext-backup-command option. Now, it only archives system settings and the --ext-backup-command option is no longer supported. Adds a restore-settings option that restores system settings, overwriting any existing settings. It operates on any valid archive directry (though ones created by backup will likely not have any system settings data).

Please refer to the updated Backup and Restore documentation for full details.

Rfe12621 - xsd:time improvements

Zoneless xsd:times are no longer converted to zero timezone when added, and timezone offsets roundtrip to and from the database. Also, with this change xsd:times and xsd:dateTimes are no longer comparable. This puts xsd:time on equal footing with xsd:dateTime. See the date and time documentation for more information.

Rfe12580 - Don't create repo if client/server uids don't match

Previously, if the uid of the direct Lisp client and the AllegroGraph server differed, then a create-triple-store call would fail with a `server-pid-and-client-pid-must-match-error` indicating that the creation failed. However, the repository would actually be created, possibly overwriting an existing repository. Now, the uid check is performed earlier in the create repository process, so that the repository is not created when the uids do not match.

Rfe12456 - Time zone roundtrip for xsd:dateTime and xsd:time

AllegroGraph previously represented xsd:times and xsd:dateTimes with Zulu (i.e. Greenwich Mean) time internally and converted data to that time zone as it was imported. On output, any xsd:time or xsd:dateTimes would be displayed in Zulu time and would lose the original time zone information. For example,


would become


AllegroGraph now keeps the original data's time zone information. Note that the additional computation involved with coercing time information during query means that queries involving xsd:dateTimes or xsd:times may run slightly (a few percentage points) more slowly. There is also a new query option, presentationTimeZone, that controls the display of time zones in the output of SPARQL queries. For example, adding

PREFIX franzOption_presentationTimeZone: <franz:-04:00> 

will cause all xsd:times and xsd:dateTimes to be printed at the -04:00 time zone. See the documentation for more information. Since the database format has been changed, the usual upgrade process involving a backup/restore cycle (see Backup and Restore) is required. Please note the following:

1: There are no changes for xsd:dates. They still support what the XML Schema describes as 'recoverable timezone'.

2: "2014-02-23T08:18:59+08:00"^^xsd:dateTime is DISTINCT from "2014-02-23T00:18:59Z"^^xsd:dateTime.

3: Joins can be made over dates that represent the same point on the same timeline even if they have different timezones. Which (equivalent) representation is returned by the join is unspecified.

See the date and time documentation for more information.

Rfe11303 - Fix partial repo creation on agraph-backup restore operations

When performing an agraph-backup restore operation, if you passed a directory name as the archive argument, the restore would fail, but not before a repository was created. Further, the repository would remain in 'restore' mode, so it could not be opened, and its existence would prevent a subsequent valid agraph-backup restore operation from succeeding. agraph-backup now first checks that the argument filename names an existing file which is not a directory before creating any repositories. Also, error messages when agraph-backup** is passed invalid archive file arguments have been improved. See Backup and Restore.

Rfe11044 - Add -p short form of --port to agraph-backup.

With agraph-backup, users may use either -p or --port to specify the port on which an AllegroGraph server is running. See Backup and Restore.

Rfe10629 - Add --supersede argument to agraph-backup

agraph-backup now accepts a --supersede option, which (if specfied) allows overwriting of existing archives (for the backup command) and directories (for the backup-all command), and databases (for the restore and restore-all commands). See Backup and Restore.

Bug22099 - Ensure UUIDs are unique during agraph-backup restores.

Previously, when restoring archive backups to an AllegroGraph server, it was trivially possible to create multiple repositories with the same uuid. Now, agraph-backup will error if a restore operation will cause a uuid conflict. See Backup and Restore.

Bug22090 - Timezone minutes in xsd types

Specifying timezone minutes is no longer optional in xsd:dateTimes and xsd:times, so the following examples are invalid:

"1978-01-03T00:00:00+05"^^xsd:dateTime INVALID  
   Correct form: "1978-01-03T00:00:00+05:00"^^xsd:dateTime  
"00:00:00+05"^^xsd:time INVALID  
   Correct for: "00:00:00+05:00"^^xsd:time 

Previously, only xsd:dates checked for the presence of timezone minutes. See the documentation for more information.

Bug22083 - xsd:date and xsd:dateTime years

AllegroGraph now correctly parses both positive and negative dates with more than four digit years. It also signals an error if the date is too large to be encoded into a UPI. Previously, dates like these were silently truncated. See the date and time documentation for more information.

Bug22073 - ORDER BY and non-encoded decimals

When non-encoded decimals were being ordered, they were first converted to IEEE 54 double floats (which have a precision of 15-17 significant digits) which potentially caused them to be sorted incorrectly. This bug has been fixed.

Bug22072 - Validate xsd:decimals

AllegroGraph now signals an error if an xsd:decimal's exponent in scientific notation is outside of the range [-63, 63] because these values cannot be encoded into a UPI. Previously, xsd:decimals like these were silently truncated.

Bug22068 - Reasoning and constant triple patterns

With reasoning enabled, some queries involving triple patterns without variables failed with 'Bus error'. This has been corrected.

Bug22066 - Printing of NaN, INF and -INF

Serialization of xsd single and double float NaN, INF and -INF was broken (for instance, INF became "#.inEinity-double"). This bug has been fixed.

Bug22057 and Bug22054- agraph-backup backup-settings works as documented.

The agraph-backup backup-settings command was incorrectly backing up data as well as settings rather than just backing up settings. Now it just backs up settings. Also, the backup-settings command now can work by finding the settings location from the config file (so the server need not be running). See Backup and Restore where a note describes all the agraph-backup revisions.

Bug22045 - 14 hour datetime comparison logic

For two xsd:dateTimes, one with and one without a timezone, all comparisons must return false if they differ by less than 14 hours. Similar logic applies to xsd:dates and xsd:times. Previously, support for this 14 hour comparison logic was spotty. It worked for some combinations (such as comparisons in a FILTER with a literal) but didn't work for others. With this fix, comparisons for all three types follow the XML Schema specification. See the date and time documentation for more information.

Bug22044 - Fix xsd:date xsd:dateTime comparisons

AllegroGraph previously compared xsd:dates and xsd:dateTimes by converting the date to a dateTime at its first instance. Because dates are actually 24-hour intervals, this logic is suspect so AllegroGraph now signals a type error if this comparison is made (i.e., FILTERs will not longer match and BIND would leave its variable unbound). The previous behavior can still be had by using an explicit cast from date to dateTime. See the date and time documentation for more information.

Bug22041 - Comparisons to decimal zero

Due to a bug in the encoding, decimal 0 appeared to be greater than all decimals less than 1.0. The usual upgrade process involving a backup/restore cycle (see Backup and Restore) is required. All misencoded decimal 0s will be converted to the correct value. If any such corrections are made during the upgrade, then indices are resorted and background index optimization is begun. The index optimization may continue even after the upgrade process has completed. The resulting indices are then as optimized as if all the triples were just imported into the database. This means if the backup was of a fully optimized repository, then after the upgrade running level 2 (the default) index optimization is necessary to get back to that state.

Bug22039 - agload character encoding fixes

Previously, the --encoding argument to agload was ignored. This has been corrected. See Data Loading for information on agload.

Bug22034 - part->concise on encoded dates and decimals

For xsd:dates, xsd:dateTimes, xsd:times and xsd:decimals, the Lisp functions part->concise and part->terse returned the stringified internal representation (like "172839/500" for decimals, and "( . )" for datetimes) which didn't fulfill the promise of being in a "human readable form". With this change, the above functions will return the value in a readable string format without the type. An example:

(part->concise (value->upi "2013-01-03T10:34:00-05:00" :date-time))  
=> "2013-01-03T10:34:00-05:00" 

See XSD Date and Time datatypes.

HTTP Client

No significant changes.


Rfe12624 - Standardize some low-level SPARQL equality tests

The efficiency and conformance of low-level tests used to compute RDFterm-equality and SPARQL ordering has been improved. One non-backwards compatible change is that AllegroGraph previously allowed ordered comparisons between plain literals that looked like numbers and typed numeric literals (e.g., "6.21" and "6.23"^^xsd:integer). This comparison now correctly throws a SPARQL type error.

Bug22092 - Fix for SPARQL queries that use the STR() function with a constant

If a SPARQL query contained a FILTER that used the STR() function applied to a constant, then the query could signal an error at planning time. For example, a FILTER like

FILTER( STR( <http:://> ) = ?var ) 

would not succeed. This has been corrected.

Bug22078 - SPARQL insert did not always encode typed literals

Triples added to a triple-store using SPARQL inserts that used computed values did not always have their typed literals encoded into UPIs. For example, an insert like:

insert { <ex:a> <ex:b> ?c . } where { bind( '1'^^xsd:byte as ?c ) } 

would store the literal in string form rather than encoding it directly. This has been corrected.

Bug22077 - Improve efficiency of certain SPARQL sub-queries

Bound variable information could be lost while processing certain SPARQL sub-query forms which would then result in less efficient query execution. This has been corrected.


No significant changes.

Changes to the Lisp API

Bug21608 - Include ag-call in remote Lisp client.

Previously ag-call was omitted from the remote Lisp client. This has been corrected.


No significant changes.


No significant changes.

Python Client

No significant changes.

Java Client

No significant changes.

AllegroGraph 4.12 user-visible changes

AllegroGraph Server: General Changes

Rfe12576 - Improve RDF/XML parser efficiency

Improve the lower-level efficiency of AllegroGraph's RDF/XML parser so that it is between 5 and 10% faster.

Rfe12522 - Global configuration directive for query options

A new global configuration directive named QueryOption was added. It can be used multiple times. Each specification is equivalent to a query prefix option. The global configuration directive "QueryOption NAME=VALUE" is the same as the query prefix option "PREFIX franzOption_NAME: ". See Server Configuration for information on configuration directives.

Rfe12429 - More flexible parsing for InstanceTimeout

With this change, InstanceTimeout configuration parameter values in the configuration file can be specified as times rather than only as a number of seconds. For example, you can use 12s, 2m or 3h to specify 12, 120 or 10,800 seconds. The configuration file is described in Server Configuration.

Rfe11010 - Require the i index for freetext queries

AllegroGraph's native freetext index requires the presence of the triple-id (i) index in order to operate efficiently. A common problem was to try to use freetext queries when there was no i index. This change automatically adds an i index whenever a freetext index is created and also signals an error if a freetext query is attempted when there is no such index.

Bug22024 - Serialization of decimals

xsd:decimals with zeroes right before the decimal point were serialized with the decimal point misplaced. This bug has been fixed. The database contents were not affected.

Bug21978 - serialize-* functions in Lisp client default to UTF-8.

Use UTF-8 as the external-format when a filename is passed to one of the serialize-* functions in the Lisp client instead of the default external format, which can vary depending on the system's locale.

Bug21976 - Complex GRAPH queries could produce incorrect graph bindings

Depending on the dataset, queries with deeply nested structure that used EXISTS or NOT EXISTS FILTERS with embedded GRAPH clauses could generate incorrect bindings for the graph variable. This has been corrected.

Bug21975 - Increase AllegroGraph Load speed

Low-level efficiency enhancements improve AllegroGraph load speed by roughly 10%.

Bug21966 - Possible "UPI not in string table" problem with remote-triple-stores

It was a possible for a remote-triple-store to lose track of the strings cached on the client after a rollback operation. This could lead to a "UPI not in string table" error. This has been corrected.

Bug21956 - Improve memory usage for zero-length property path queries

A zero-length property path query connects all subjects and objects on the right and left hand sides of the path to themselves. If the store is large and the path produces many matches on one or both sides, AllegroGraph was using more memory than necessary. This has been greatly improved though some queries may experience a slight performance degradation.

Bug21954 - Problem generating soundexes for phrases in Callimachus

If a store was operating in Callimachus mode and a phrase was soundexed that had words in it with no soundex (e.g., a number) then AllegroGraph would generate garbage soundex data. This has been corrected

Bug21949 - Improve bookkeeping of already processed variables during query execution

AllegroGraph was not updating the list of bound variables when evaluating a BIND clause during query execution. This did not change the final results of a query but did mean that AllegroGraph would not always evaluate the query in the most efficient manner. This has been corrected.

Bug21937 - Zoneless xsd:dateTime roundtrip

Adding a triple with an xsd:dateTime without a timezone (e.g. "2013-07-30T23:59:59") was stored as if it had a timezone of zero. With this bug fix, zoneless dateTimes are stored and serialized without timezone. This is in agreement with the XML schema specification and similar to how xsd:dates behave.

Bug21934 - String table mutex not reinitialized after recovery

A mutex used in the string table data structure was not being reinitialized after database restart. Under certain circumstances this could result in a database hanging after restart. This problem has been corrected.

Bug21920 - Soundex should ignore punctuation

AllegroGraph's soundex function (which is used by Callimachus) was not ignoring punctuation properly. This has been corrected.

Bug21915 - Make upi->value on xsd:dates return integers

Due to an undocumented change in v4.11, upi->value on a upi encoded as :date returned a cons of the integer representing the instant and a flag indicating whether the timezone was present. With this change only the integer part is returned (like before v4.11). The flag is returned as the second value by upi->values.

Bug21914 - xsd:dates on the first day of the month

Adding a triple with an xsd:date with a positive timezone that falls on the first day of a month resulted in error "illegal date 0". This bug has been fixed.

Bug21909 - agraph-backup could fail to generate unique UUID on restore

When using the --newuuid option, it was possible for agraph-backup to create multiple triple-stores with the same UUID. This has been corrected. See Backup and Restore for information on agraph-backup.

Bug21903 - Free text indexing with chunk-at-a-time processing

Depending on the execution plan, a query that used both fti:match and chunk-at-a-time processing (see franzOption_chunkProcessingAllowed) could produce too few results. This bug has been fixed.

Bug21899 - Shared memory server fails to clean up

Under low memory conditions, the shared memory server can fail to allocate blocks of shared memory on behalf of a database instance. Under certain circumstances the shared memory server would fail to clean up from partial allocations, thereby exacerbating the low memory condition. This problem has been fixed.

Bug21873 - Link to docs in rpm install

When AllegroGraph was installed from an rpm package, the documentation links in AGWebView were broken. This bug has been fixed.

Bug21872 - agload will write output to agload.log when in --debug mode

Along with the other effects of using the --debug command line argument to agload, all output will be logged to agload.log. See Data Loading.

Bug21869 - Fix problem with registering cartesian predicate mappings

There was a problem which prevented the shortened form of cartesian predicate mappings from working. This has been corrected.

Bug21853 - Connection Pool session port connection failure

Under certain circumstances, the AllegroGraph Java client would throw an exception like the following:

Possible session port connection failure 

Setting the SessionPorts configuration parameter is discussed here in Server Installation and also in Server Configuration. But this exception could occur even with a proper SessionPorts setting. This problem has been resolved.

Bug21846 - Long running federated queries could fail

The query canceling interface introduced in AllegroGraph 4.11 could lead to query failures when using federated triple-stores. This has been corrected. Note that it is not currently possible to cancel queries running on a federated store. This will be improved upon in a future release of AllegroGraph.

Bug21816 - Fix session multiplexing file descriptor leak

When requests to sessions are multiplexed through the server's main port, the frontend didn't close the http socket used to communicate with the session process. This bug has been fixed. Note that session multiplexing can be enabled for the java client by setting the system property:


Bug21784 - Safer auto-close for garbage db's in the Lisp direct client

The db's are now marked for closure when it is noticed they are no longer used and closed at a later specific time.

Bug18813 - Reasoning and subclasses of owl:TransitiveProperty

With this fix the reasoner is able to infer that a property whose type is a subclass of owl:TransitiveProperty is a transitive property. That is,

:p rdfs:subClassOf owl:TransitiveProperty .  
:q rdf:type :p .  
:a :q :b .  
:b :q :c . 


:a :q :c .  

HTTP Client

No significant changes.


Rfe12822 - Add temporaryFileDiskSpace query option

Sometimes queries write intermediate results to disk when they will not fit in memory, for instance with an ORDER BY query. With a huge query it is possible for a such temporary files to fill the filesystem. In order to prevent this, the temporaryFileDiskSpace query option may be set. For example:

PREFIX franzOption_temporaryFileDiskSpace:

As with all query options, it is also possible to change the default value globally in the AllegroGraph configuration file. For example:

QueryOption temporaryFileDiskSpace=10G

The default is to have no limit. Query options are described here in the SPARQL Reference.

Rfe12537 - Improve zero length property path clause estimation

This change improves the heuristics AllegroGraph uses to estimate the number of rows that a zero length property path query can generate which improves the way AllegroGraph processes a BGP.

Rfe12520 - The SNA members and size magic properties work with RDF lists

You can now use the and magic Properties to query RDF lists stored in your triple-store. For example, if points to the head of the RDF list "1", "2", "3", then this query would return the three elements:

prefix sna: <>  
select ?item {  
  <ex:list> <ex:pointsTo> ?list .  
  ?item sna:members ?list .  

Would return "1", "2" and "3". See SPARQL Magic Properties for SNA.

Rfe12506 - Improve handling of some queries that use GRAPH clauses

SPARQL is defined such that a query like

GRAPH ?g { A } 

should behave as if A was evaluated with ?g bound to each graph in the dataset in turn and then the results of all of these evaluations were unioned together. While correct, this implementation can be very inefficient. AllegroGraph uses various heuristics to determine if a given GRAPH clause can be evaluated more directly and does so when it can. This change improves these heuristics so that more queries will be able to use the more efficient implementation.

Rfe12481 - Improve SPARQL DELETE efficiency

This change greatly increases the efficiency of the DELETE portion of a SPARQL DELETE... INSERT... WHERE... command. The actual increase is dependent on the data and the delete template but it can be more than 40 times faster.

Rfe12442 - Efficiency improvements for SPARQL aggregation

Optimize the code used for SPARQL aggregate queries in general and for count aggregates in particular.

Rfe12400 - Minor property-path query optimization

Improve the underlying efficiency of some property-path queries.

Rfe12398 - Clarify semantics of the identity clause reorderer

AllegroGraph has two clause reorderers which try to preserve the ordering of triple-patterns in a BGP (basic graph pattern). Previously, these were named:

To avoid future confusion, these options are being renamed such that the first method is called :weak-identity and the second is called :identity.

The default query clause reorderer continues to be statistical so queries that do not specify a reorderer will behave exactly as they did before this change.

Rfe12392 - Optimize certain complex join combinations

The query optimizer now converts a query with an algebra like:

(:join (:join A :bgp1) :bgp2) 

into the equivalent:

 (:join A :bgp1-and-bgp2) 

This BGP (basic graph pattern) merger improves AllegroGraph's ability to reorder queries for efficient execution. AllegroGraph also converts the expression:

(:join (:join :bgp1 A) :bgp2) 


(:join :bgp1-and-bgp2 A) 

unless the two BGPs do not overlap (in which case the transform would produce a cross-product).

Rfe12385 - Improve BGP reordering in some cases

In some cases, the SPARQL query planner now does a better job reordering the triple-patterns in a BGP (basic graph pattern).

Rfe12380 - Improve efficiency of some DISTINCT or REDUCED queries

AllegroGraph now collects fewer intermediate results for some DISTINCT or REDUCED queries.

Rfe12377 - Add intervalContainsTime magic property

Added an additional temporal magic property that can be used to determine if a time is contained within an interval. See SPARQL Magic Properties.

Rfe12372 - Make BGP reordering more intuitive

Previously, AllegroGraph would switch the execution of patterns in a BGP when the BGP contained only two patterns and these patterns had the same statistical clause estimates. E.g., in a query like:

?a ?b ?c .  
?c ?d ?e . 

AllegroGraph would execute the second pattern first. AllegroGraph now executes the first pattern first in the case of ties which is more intuitive.

Rfe12368 - Use constraints to limit bindings for GRAPH queries

Improve AllegroGraph's use of FILTERs in limiting the graphs considered in GRAPH clauses with variable graphs. For example,

GRAPH ?g { A }  
FILTER( ?g = <ex:test> ) 

will now be evaluated more efficiently since AllegroGraph will only consider the graph <ex:test> rather than every graph in the dataset.

Rfe12352 - Provide a sort order for SNA path and group gensyms

Social Network Analysis (SNA) magic Properties can create node identifiers to keep track of paths and groups. These act like blank nodes and so had no sort order defined for them. This was inconvenient because it made it impossible to, for example, list all of the nodes of a path together. This change adds a sort order to these node identifiers so that they are easier to use in queries.

Rfe12192 - Optimize some wild-card property-path queries

AllegroGraph now computes property-path queries that use the * or + operators more efficiently.

Rfe12032 - Improve property-path expansion

AllegroGraph now expands more property-path queries into their equivalent BGPs (basic graph patterns). This can improve the performance of the query optimizer. For example, AllegroGraph previously expanded

?s :a/:b ?o .  

?s :a :b0 . :b0 :b ?o .

but did not expand paths with non-simple operators like wild-cards or alternation. It now expands these as well so that a path like

?s :a/:b/(:c|:d)/:e/:f ?o 


?s   :a _:b0 .  
_:b0 :b _:b1 .  
_:b1 (:c|:d) _:b2 .  
_:b2 :e _:b3 .  
_:b3 :f _?o .  

Rfe11948 - Add PREFIX option for enabling reasoning in a SPARQL query

AllegroGraph's SPARQL 1.1 engine now supports the inferenceMode query option to control the kind of inference used by an individual query. The mode is selected using the query option PREFIX notation. For example, the following PREFIX would cause a query to be evaluated using AllegroGraph's RDFS++ reasoner:

PREFIX franzOption_inferenceMode: <franz:rdfs++> 

The following modes can be supplied:

Rfe11625 - Improve algebraic optimizations of joins and left-joins

Improve the logic used in the algebraic transform of

(:join (:left-join A B) C) into (:left-join (:join A B) C) 

Which is the textual equivalent of moving the optional clause down in a query like

optional { B }  

so that it becomes

optional { B } 

which can be evaluated more efficiently unless A and C share no bindings.

Rfe11146 - Handle simple OPTIONAL clauses more efficiently

AllegroGraph now handles OPTIONAL clauses that contain only a single triple-pattern more efficiently. This means that queries with clauses that look like

 ?s :predicateA ?o .  
 OPTIONAL { ?s :predicateB ?b }  
 OPTIONAL { ?s :predicateC ?c } 

will be processed more efficiently.

Rfe11068 - Improve literal equality constraint handling

AllegroGraph now handles filter expressions involving literal equality more efficiently. For example, in a query like

select * {  
  ?a :predicate ?b .  
  filter( ?b = 'literal' )  

AllegroGraph previously would scan all triples with the given predicate and apply the filter afterwards. Now AllegroGraph determines the set of possible matches for 'literal' and queries for them directly.

In addition, AllegroGraph now performs a similar operation if the filter is a literal equality on an expression using the SPARQL str function. For example:

filter( str(?variable) = 'searching' ) 

As with regular literal equality constraints, such an expression is converted into the equivalent tests for specific values.

Bug22030 - ORDER BY expressions with non-query variables could cause errors

If a SPARQL query used an ORDER BY expression that contained variables that were not found anywhere in the query, then an error could result. An example of this would be a query like:

select * {  
  ?s a ?o .  
} order by desc( str( ?notFoundInQuery )) 

This issue has been corrected.

Bug22021: Correct SPARQL TSV printing problem for encoded UPIs

When encoded UPIs were serialized from a SPARQL query using the SPARQL TSV (tab sepated values) output format, they were printing without the enclosing quotes. This has been corrected.

Bug22016 - Correct SPARQL 1.1 bug with IN FILTERs

It was possible for the query engine to produce incorrect results when using FILTER with either the SPARQL IN operator or multiple equality filters on the same variable. This has been corrected.

Bug22015 - Fix possible error when using the SPOGI cache and SPARQL 1.1

In rare circumstance it was possible for a SPARQL 1.1 query to signal an error when the SPOGI cache was enabled. This has been corrected.

Bug21986 - Using distinct aggregation with GROUP_CONCAT and a separator could fail

If a SPARQL query used the GROUP_CONCAT aggregator along with both the DISTINCT and SEPARATOR modifiers, then the solution bindings for that variable could be left empty. This has been corrected.

Bug21980 - Too many results in DISTINCT and REDUCED queries

Under extremely rare circumstances, queries involving DISTINCT or REDUCED could return too many results. This bug has been fixed.

Bug21974 - Assertion failure involving 'n-valid-partials'

When chunk-at-a-time processing was enabled (see query prefix franzOption_chunkProcessingAllowed, described here in the SPARQL Reference), the code keeping track of the number of intermediate results used to run into an assertion failure under very rare circumstances (when two consecutive intermediate results were the same). This bug has been fixed.

Bug21962 - Improve estimates for certain query patterns

AllegroGraph was mis-estimating the sizes of query patterns that resulted from the inlining of filters that used the IN expression. For example,

?s ?predicate ?object .  
FILTER( ?predicate IN ( ex:a, ex:b, ex:c ) 

This could result in sub-optimal BGP re-ordering. This has been improved.

Bug21961 - Incorrect results with EXISTS and NOT EXISTS

Some queries involving EXISTS or NOT EXISTS filter expressions returned too few results. This bug has been fixed.

Bug21955 - Sorting on unbound variables could lead to a string dictionary error

If a query used an ORDER BY expression involving a computation and some of the variables in the expression were unbound, then the expression could signal a UPI not in string dictionary error. This has been corrected.

Bug21948 - Improve bookkeeping of bound variables during sub-query

When executing a sub-query with a limit, AllegroGraph failed to update the list of variables known to be bound. This prevented some queries from executing as efficiently as possible. This has been corrected.

Bug21947 - Improve efficiency of VALUES in some cases

AllegroGraph now does a better job of using the information in a VALUES clause to restrict alternate solutions. This can greatly increase the speed of some queries.

Bug21941 - Queries with magic properties could fail in a remote-triple-store

Queries that used magic properties could cause an error when run from a remote-triple-store. This has been corrected.

Bug21940 - Using magic properties with filters could lose solutions

If the circumstances were just right, a query that used a magic property that produced multiple bindings and that used a filter on those bindings could fail to return all solutions. This has been corrected.

Bug21933 - Externally introduced variables could fail in nested sub-queries

If a query used externally introduced variables (e.g., via the Lisp APIS's with-variables argument or via the variable bindings in an HTTP REST request), and these variables were used in FILTER clauses in a nested sub-query, then the query could fail to find any matches. This has been corrected.

Bug21921 - BGP triple filters with Chunk-at-a-Time processing

In rare cases, a filtering triple-pattern could fail to remove some solutions when using Chunk-at-a-Time query processing. This has been fixed.

Bug21902 - Fix incompatibility between magic predicates and the identity reorderer

If the identity BGP clause reorderer was being used in a query with magic predicates, then the magic predicates were being sent to the end of the BGP. This has been corrected.

Bug21901 - Minor improvements to some range query clause orderings

Improve the statistical estimates used to reorder BGP patterns that use range queries.

Bug21892 - Query engine selection failed to take OFFSET into account

AllegroGraph's decision on whether to use the single-set or the chunk-at-a-time query execution engine relied only on the LIMIT of the query rather than the LIMIT and the OFFSET. This has been corrected.

Bug21880 - Using with-variables in SPARQL describe caused an error

Using SPARQL describe with an external variable binding would lead to an error at query execution time. For example, this query would fail:

 describe ?x 

(where ?x was bound externally). This has been corrected.

Bug21865 - Comparisons of xsd:dateTimes with fractional seconds

Comparisons (including ORDER BY) of xsd:dateTimes with fractional seconds were broken. This bug has been fixed.

Bug21862 - Some FILTERs and BGP orderings could lead to empty bindings

In rare cases, AllegroGraph could fail in its bookkeeping of which variables were bound while it executed a query. This could lead to the introduction of spurious rows with null bindings. This has been corrected.

Bug21858 - Distinct, SERVICE and sub-query could lead to planning failure

If a query used a sub-query in a SERVICE clause and asked for unique results, then AllegroGraph would signal an error during query planning. This has been corrected.

Bug21852 - Improve bound variable tracking

AllegroGraph should assume that any variable supplied via external settings (e.g., via the with-variables parameter to run-sparql) is bound. Failure to do so could cause some queries to fail. This has been corrected.

Bug21828 - VALUES could fail to correctly handle OPTIONAL bindings

Using the VALUES clause could incorrectly drop solutions whose rows contained unbound values. This has been corrected.

Bug21815 - Fix property-path memory leak

Some queries involving property-path expressions could run out of memory, because the intermediate result set was not freed as soon as it was consumed. This bug has been fixed.

Bug21803 - Exclusive ranges of encoded non-integer types

Previously, filter expressions on all non-integer types (floats, decimals, etc, excluding xsd:date and xsd:dateTime) involving exclusive ranges ('<' and '> ') behaved as if an inclusive range ('<=', '> =') had been specified. This bug has been fixed.

Rfe12591: Improve efficiency of some Basic Graph Pattern evaluations

AllegroGraph now makes better use of intermediate result sets when evaluating basic graph patterns (BGPs) in nested groups of joins and left-joins.


Bug21997 - Agwebview and sessions

Due to a thread safety issue, AGWebView's 'Create Session' or any subsequent action in that session could produce garbage results ranging from 'Not found' to garbled output. This bug has been fixed.

Changes to the Lisp API

Rfe12562 - upi->value round-trip

For dates and date-times a complete representation is a (<universal-time> . <timezone-information>) cons. While this would make a good candidate for the return value of upi->value, to maintain backward compatibility by default upi->value must return a single number representing the universal time.

However, this means that during the upi->value/value->upi round-trip the timezone information is lost.

This change adds a new keyword argument :complete? (defaults to nil). With :complete? t, upi->value returns the complete representation and the roundtrip works in the sense of:

(upi= (value->upi (upi->value upi :complete? t) (upi-type-code upi))  

Currently, for UPIs other than dates and date-times, :complete? has no effect.

Rfe12557 - run-sparql can now use a UPI or future-part for the default base

Previously the Lisp function run-sparql only allowed a string to specify the default-base. It can now take a string or a UPI or future-part.

Rfe12508 - normalizing with-variables should convert $var to ?var

The with-variables parameter in the Lisp API to run-sparql allows for variable names to be identified as strings or symbols. The name can be a plain string like "person" or a string whose first character is #\? or #\$ like "?person" or "$person". All three of these representations refer to the same query variable: ?person. Prior to this change, AllegroGraph could misinterpret variable names that used $ as the first character. This has been corrected.

Bug21953 - Support server-side loading via the Lisp client.

When using the Lisp client and connected to a remote-triple-store, passing a URI or URI-like string to one of the bulk-load functions (e.g. load-ntriples) will cause the resource to be loaded directly by the server instead of being delivered via the client.

Bug21891 - db.agraph.log:log-output captured in dumplisp

If dumplisp (a function used to save a running image) was used after opening a triple store, the stream used for logging would be captured. Upon restore of the dumped image, subsequent logging attempts (performed by internal AllegroGraph code) could result in confusing errors or file corruption. This has been fixed.

Bug21860 - Make Lisp clients find bundled

Previously, Lisp clients resorted to using the liblzo library located in the acl directory ("sys:") or somewhere the OS dynamic library loader can find it. With this change the bundled is loaded.

Bug21841 - db-get-triple leaks sockets

The Lisp function db-get-triple didn't close the socket it used for communication with a remote triple store which resulted in leaking sockets in CLOSE_WAIT state. This bug has been fixed.

Bug21848 - load-turtle could use the wrong triple-store

The load-turtle command could fail to respect the value of the db parameter and instead load triples into the store currently bound to db. This has been corrected.

Bug21810 - Polygon-vertexes did not work with future-parts

If called with a future-part rather than a UPI, the polygon-vertexes function would return no results. This has been corrected.

Bug21611 - Load patches in Lisp remote client

With this fix the Lisp remote client loads patches and enables pretty printing of parts and triples just as the direct client does.

Bug21070 - Fix corruption hazard in direct Lisp client.

Prevent possible database corruption that could occur when interrupting a direct Lisp client app that is modifying the transaction log.

Bug21045 - create-freetext-index function failed when called with UPIs

The create-freetext-index function (in the Lisp API) would fail if called with UPIs (rather than, e.g., future-parts). This has been corrected.


Rfe12222 - AllegroGraph Prolog unifies UPIs and future-parts

When AllegroGraph is loaded, the semantics of Prolog unification is extended such that:

This enhancement does not change the capabilities of Prolog queries in AllegroGraph, but allows simpler, less-verbose coding that looks a little more declarative and less procedural. For example, the following

(select (?manager ?employee)  
  (member ?employee (!acme:joe !acme:jill !acme:jim !acme:jerry))  
  (q ?employee !acme:hasManager ?manager)  
  (member ?manager (!acme:bill !acme:bob !acme:betty !acme:benjamin))) 

would not work as intended before this change because ?manager would be unified with a UPI, and a UPI would not unify the future-parts in the last clause. The last clause would have had to be coded as something like

(member ?manager1 (!acme:bill !acme:bob !acme:betty !acme:benjamin))  
(part= ?manager manager1) 

Using Prolog is AllegroGraph is documented here in the Lisp Reference.


No significant changes.

Python Client

No significant changes.

Java Client

Bug21953. Fix generation of some POST method requests.

AGHTTPClient would write query parameters to the body of POST requests when the content-type was not application/x-www-form-urlencoded. This can result in http servers not finding the query parameters and processing the request incorrectly. This bug corrects the problem by writing POST request query parameters to the URL, unless the request has no body and the content type is application/x-www-form/urlencoded. AGRepositoryConnection.load() (see Javadocs) now works for importing server-side statements.

See Change History for user-visible changes to earlier releases.