-
Notifications
You must be signed in to change notification settings - Fork 26
Siena v1.0.0 Draft Doc
mandubian edited this page Mar 21, 2011
·
1 revision
Welcome to the siena Github Wiki!
The aim of this wiki is to present quickly the features provided within current siena source.
When the code is stable, the documentation will be moved to Siena website http://www.sienaproject.com.
Current version being developed is Siena v1.0.0
Last tag is Siena v1.0.0-b1
-
Asynchronous mode for GAE (JDBC will come soon)
- based on Java Future concept ported to Siena and simplified with respect to exceptions management
- maps all existing and also new synchronous APIs to asynchronous APIs
-
Stateless/stateful queries (stateless is the default mode and the one you already know)
- for those who reuse queries several times and keep the query context between 2 calls
- means the cursors, offsets are kept alive between calls
- provided for JDBC based on prepared statements reuse
- provided for GAE based on GAE cursors reuse
- can be mixed with asynchronous mechanism
- mechanism of dump/restore of stateful queries in order to be able to restore a query context later (very useful for pagination for example)
-
Pagination for JDBC/GAE forward/backward (in stateful/stateless and synchronous/asynchronous mode)
-
Iteration for JDBC/GAE (in synchronous/asynchronous mode)
- allowing to realize the mapping from DB objects to Java objects dynamically when a new iteration is done and not at once after DB extraction
- available for pagination also
-
Batch mode for GAE/JDBC
- provides select/update/insert/delete in batch mode allowing requests on many entities at once
- java enum are well managed now
- primary keys can be Long/String/UUID for GAE/JDBC
- join mechanism for JDBC and simulated for GAE (need some more reflections on this based on GAE groups but it already works even if it might not be optimized)
-
Search for GAE/JDBC
- for GAE, it is really simple search with respect to limitations of GAE (don't imagine ElasticSearch or Solr but anyway, it's practical sometimes)
- for JDBC, the search can be customized according to the DB because it is one of the main feature which is not really portable between MySQL and Postgres but basic code will work on both side (and on GAE also).