polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kent SĂžlvsten <kent.soelvs...@gmail.com>
Subject Re: GeoSpatial Query support
Date Thu, 11 Jun 2015 07:20:27 GMT
While I agree that the goal of decoupling the query part from core is a
worthy one, I fail to see what UnitOfWorkFactory has to do with that.

Decoupling the UnitOfWork may or may not make sence, but I think that is
another discussion - which could make sense eg. if you wish to integrate
a Zest application with an XA transaction manager.

Since the EntityFinders are responsible for executing a Query it makes
since to me to let the EntityFinder be involved in creating the query.
So a possible design could be to simply break out the querybuilder API's
form core. No more, no less.

Let us say that the core API only consists of

public interface QueryBuilder<T> {
  Query<T> newQuery( UnitOfWork uoq );

public interface QueryBuilderFactory {
    <QB,T> QB<T> newQueryBuilder( Class<QB extends QueryBuilder>
builderType, Class<T> resultType )
        throws MissingIndexingSystemException,

Query interface still in core, looking as of today.

QueryBuilderFactory should no longer be embedded inside the module, but
instead be a service (probably implemented by the extension that also
implements the EntityFinder).

Concrete QueryBuilder interfaces/impls and Query implementations are
moved to libraries (one library implementing SpecificationQueryBuilder,
another implementing SparQLQueryBuilder ....)

Application code could then be something like:

        SpecificationQueryBuilder<Person> sqb =
this.module.newQueryBuilder( SpecificationQueryBuilder.class,
Person.class ); // h
        Property<String> nameProp = templateFor( Person.class ).name();
        sqb = sqb.where( eq( nameProp, "Kent") );
        Query<Person> query = unitOfWork.newQuery( qb );

        SqlQueryBuilder<Person> sql = this.module.newQueryBuilder(
SqlQueryBuilder.class, Person.class );
        sql = sql.where( "name = 'Kent'");
        Query<Person> query = sql.newQuery( unitOfWork );  // this
QueryBuilder might have a special query implementation
        SesameQueryBuilder<Person> sesame = this.module.newQueryBuilder(
SesameQueryBuilder.class, Person.class );
        sesame = sesame.bySparql( queryString);  // this queryBuilder is
now probably immutable
        Query<Person> query = sesame.newQuery( unitOfWork );  // this
QueryBuilder might have a special query implementation

Some of the QueryBuilder libraries might only consist of an API
(implementations supplied by the extension also supplying the
EntityFinder) - other libraries might have a default implementation to
facilitate several entitystores supporting that Query 'language'.
Note that some EntityFinders  might support several Query 'languages',
both a specification based and a native one.

We might even some day be able to support JPA or Hibernate, allowing the
user to create a Zest app combining existing data in a relational
database with geospatial data? (that would probably require some
re-thinking of the UnitOfWork concept).

Am I making sense?


Den 06-06-2015 kl. 05:41 skrev Niclas Hedhman:
> Thanks Martin, that gives a nice overview of the situation (you should
> plaster that on frontpage)...
> Zest gang,
> So, I think our challenge is to be able to introduce Geospatial
> indexing/querying, without introducing a dependency.
> What do I mean by this?
> Well, we already have another "Custom Query" type, the Lucene free-text
> search, which couldn't be fitted nicely into the very nature of the
> UnitOfWork/QueryExpressions/QueryBuilder system.
> So let's hypothesize about;
>   * Ability to introduce new indexable data types,
>   * Ability to introduce extensions to the Query DSL
>   * Ability to extend the Indexing/Query extension itself.
> Where is the root of this system? Well, it all begins in the UnitOfWork.
> So, one possibility would be to disconnect UnitOfWorkFactory from the
> Module itself, and have a ServiceComposite for the UnitOfWorkFactory. Once
> the UnifOfWorkFactory implementation is outside the Core Runtime, so is
> UnitOfWork and everything that derives from it. It SHOULD mean that all
> parts could be Composites, in which case we can add arbitrary methods to
> them, the static methods of QueryExpressions could go away and probably
> other, yet to be discovered, benefits.
> Granted, it won't be common for users to create their own, but having this
> possibility, without becoming incompatible and without introducing
> dependencies in the Core, seems to me to be worthwhile going down this
> route. Having such a major part of the Core to be on the "Composite-side of
> things", might open up more cool ideas...
> It also feels "right" along our habit of breaking things out of Core and
> moving towards more modularity.
> On paper, it sounds reasonably easy to do this, but I bet the devil is in
> the details. Maybe an impossible circular dependency will arise, or
> something to that extent.
> Any thought on this?
> Cheers
> On Fri, Jun 5, 2015 at 4:57 PM, Martin Desruisseaux <
> martin.desruisseaux@geomatys.com> wrote:
>> Thanks Chris for getting Zest and SIS in touch. I just finished reading
>> the thread. There is some tips for information purpose:
>> Niclas Hedhman wrote:
>>> So, IF SIS are primarily based around interfaces, then that would be
>>> great and we can possibly leverage quite a bit, especially at what we
>>> call "Library" level, i.e. not part of the Core runtime itself, which
>>> we try to keep free of dependencies
>> The core part of SIS is defined by a set of interfaces provided by a
>> separated project: http://www.geoapi.org/. GeoAPI consists of only
>> interfaces, except some classes for Exception, Enum and "CodeList"
>> (similar to Enum but extensible). GeoAPI is based on some international
>> standards published jointly by the Open Geospatial Consortium (OGC) and
>> International Organization for Standardization (ISO). It currently
>> covers only a small part of OGC standards, but this includes map
>> projections.
>> Apache SIS is a GeoAPI 3.0 implementation. The GeoAPI project provides
>> also implementations as wrappers around Proj.4 (the C/C++ library used
>> by GDAL) and the UCAR NetCDF library. All those projects have advantages
>> and inconvenient (e.g. Proj.4 supports a wider range of map projections
>> than SIS, but SIS is more compliant with OGC/ISO standards). But if Zest
>> depends directly on only GeoAPI interfaces you would have the freedom to
>> change implementation. However I do not know if Spatial4J would be
>> interested to implement GeoAPI interfaces.
>> On geometry and indexing, there is no satisfying solution on GeoAPI side
>> yet. In particular, geometries are defined by the ISO 19107
>> international standard, which is currently under revision. This will
>> have a deep impact on GeoAPI once the ISO revision will be completed.
>> Please let us know if you would like to explore further (e.g. how to
>> apply a map projection using the API defined by GeoAPI).
>>     Martin

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message