Recent changes to feature-requests

Sporadic Meta Data

2006-11-08T00:59:55Z

It appears from looking at the code and running test
cases against my database that SQLREST attempts to
build a complete meta data structure of the database.
This can be very expensive in terms of time (esp. if
the DB connection is remote) and resources for large
databases, which is the case for me.

Rather than constructing the meta data in an
initialization phase might I recommend that the meta
data is queried from the database and constructed on
demand so that the meta data structure is sporadic.
This should decrease load time and only load those
parts of the schema when required.

For instance if a simple http://hostname/sqlrest/ GET
was done you would only have to look up the table
names and not the structure of the tables. Each table
structure would only have to be populated when a
request to that specific table was made.

Another advantage to this approach is that the meta
data maintained in memory could be constrained by
size etc. to keep the runtime footprint smaller.
(i.e. it is a meta data cache such that meta data
which has not been used for a while is released from
the cache).

Support mapping to multiple DB sources

2006-11-06T21:36:52Z

It might be nice if SQLREST would allow the
specification of mutiple DB sources so that it could
front end connectivity via a single HTTP end point to
these databases making it an integration interface
across multiple resources. At the same point it would
be useful to be able to specify the list of
tables/views which you would like published as
resources.

A config of the style:

<sources>
<source>
<name>source1</name>
<datasource>
<jdbc-driver-class>org.hsqldb.jdbcDriver</jdbc-
driver-class>
<database-
url>jdbc:hsqldb:hsql://localhost</database-url>
<user>sa</user>
<password></password>
</datasource>
<resources>
<resource>
<url>/level/level/resource</url>
<table>TABLE_VIEW_NAME</table>
</resource>
</resources>
</source>
<source>...</source>
<source>...</source>
</sources>

Drive resource mappings from config instead of DB meta data

2006-11-06T21:28:21Z

Right now it appears that SQLREST derives the
resource definitions based on the TABLE structure of
the database. Often a database may contain
information about a single object in mutiple tables.
I would be nice to be able to manually control the
structure of the resources based on a configuration
file such as the following:

<operations>
<operation name="put"></operation>
<operation name="get">
<parameters>
<parameter name="id" />
</parameters>
<map>
<sql>
select col1, col2, col2 from table where
uid='{id}'
</sql>
<mapping>
<map column="col1" to="xpath" />
<map column="col2" to="xpath" />
<map column="col3" to="xpath" />
</mapping>
</map>
</operation>
</operations>

I am by no means a REST expert, so what is above may
not make sense, but I think by controlling the
structure of the resources the designer would have
better control and be better able to handle database
schema evolution.

One could argue that you could do much of the same
using read/write views I suppose and perhaps that
would be a better mechanism.

Support for partial content

2003-04-25T10:59:12Z

It shoud be possible for long lists, to retrieve it in
Parts. See SC 206 Partial Content

Bundling with RESTGate

2003-04-23T17:10:15Z

Bundle sqlREST with a RESTGate runtime

Schema for the XML responses

2003-04-21T17:34:31Z

Provide schema information for the responses. Either
one schema for all responses or on-the-fly generated
schema based on the database metadata.

Overview page

2003-04-19T13:32:52Z

Page with the essentials

Links to REST resources

2003-04-19T09:31:34Z

Section in the documentation with links to REST
documents, Like Thomas Roy Fieldings dissertation and
the REST Wiki.

Example client code

2003-04-19T09:29:44Z

Java examples code for POST, GET, DELETE and PUT requests.

FAQ

2003-04-19T08:30:05Z

FAQ for sqlREST and some REST questions