Elda 1.3.24

[chris dollin]

Dear All

We are pleased to announce the release of
Elda 1.3.24 (Elda's 1.3.23, .22, .21 made small
correctional changes only. It addresses a regression
on the treatment of empty lists, a memory leak, and
a failure mode for reloading configurations.

#179 -- empty lists defaulted to 404ing, a regression that needed
to be fixed. Empty list endpoints now default to rendering as an empty
list (item endpoints 404 by default).

#177 -- elda stored repeated runs of reloaded configurations which
lead to running out of room. The entire SpecManager family of
classes has been rewritten so that any given config file has at
most as many configurations loaded as were present in the last
version of the config file. Because Elda now keeps track of which
config has which API endpoints, /lda-config will no longer display
configs that have no endpoints rather than displaying them but
giving them no endpoints.

In earlier versions of Elda, if the initial load of config
fails (eg because of a syntax error in the Turtle file) then
Elda did not allow access to any endpoints and it was not possible
to fix this by updating the config file. The changes for #177
also fix this; broken configs are logged and then treated as
empty.

The Elda git repository is

https://github.com/epimorphics/elda

Elda is available as Maven artifacts as per the pom
found at

https://github.com/epimorphics/elda/blob/master/pom.xml

Chris

--
Chris "allusive" Dollin

[Richard Walker]

On Thursday, March 9, 2017 at 8:11:37 PM UTC+11, chris wrote:

We are pleased to announce the release of
Elda 1.3.24

Big public applause for Chris for (a) all the hard work,
which is evident from the commits,
(b) doing the fixes so soon after I reported the issues.

We use the Elda library in a production service, and these fixes
are _very_ important.

/lda-config will no longer display
configs that have no endpoints rather than displaying them but
giving them no endpoints.

So a question that popped into mind that I guess I could
test but it's quicker to ask: does this mean that deletion
of a spec file now works to delete the endpoints contained
in it? We currently "zero" (i.e., truncate) the file instead as
a workaround, precisely because deleting the spec file _didn't_
delete the endpoints.