News

New query feature: Native Query

Added by achristian almost 5 years ago

Beside the standard query mechanism, where developers can implement their own query condition, there's now a new mechanism called native query.

With the normal query, each stored object of class XYZ is compared against the condition-implementation. For only a few objects this is maybe acceptable. But if you have several hundrets or thousand objects of one type, the query will be too CPU intensive and time consuming.

The new native query enables you to specify your query with a native API.

An example:

Mission: Get all stored objects of type MySpecialClass which have integer field "myIntValue" in range 50..100

Old Query:

Query query = storage.query(MySpecialClass.class);
query.setCondition("myIntValue", new Condition<Integer>() {

      @Override
      public boolean condition(Integer variable) {
          if (variable>=50 && variable<=100) {
              return true;
          }
          return false;
      }
});       
List resultList = query.execute();

Internally, all stored objects of type MySpecialClass are feed into the condition-implementation. So all objects have to be watched. The more objects you have stored, the longer the query takes ---> O(n).

New native Query:

NativeQuery query = storage.nativeQuery(MySpecialClass.class);
query.setCondition(Logic.and(Comparison.ge("myIntValue", 50), Comparison.le("myIntValue", 100)));
List resultList = query.execute();

With the new API you can of course create a condition with many different field...
No matter how many objects you have stored. SOS translates your native query into a query that is natively understandable by the used backend. So runtime is considerably less than O(n).

Backend changed ...

Added by achristian about 5 years ago

Last weekend I found some time to work on SOS. The file-based backend was fault-prone and not running stable enough. Instead of inventing the wheel (file as database structure) again, I switched the backend to a sql-based backend. This a) improves performance (as the file-backend of the SQL database is well tested)
b) saves development-time
c) opens us some cool features in future, like store on network, store in cluster, ... but this is still future music ...

(1-3/3)

Also available in: Atom