(Sorry I can't inline the answers from the phone)
1. The type is not "lost". The Property.type() will provide the generic type
of the Property. But that is at client level. The EntityStore SPI hands an
EntityType descriptor down to the ES for it to use if it wants. Some ES will
use this for mapping purposes, others mainly ignores it.
So, just like there will be ORM issues if the POJO field is changed from one
type to another without correction in previously stored data, so there will
be in Qi4j. HOWEVER, we also provide a Migration API (not fully finalized
yet) so that you can take corrective action at the data level before the raw
data is converted into State.
2. With "unique constraint" I assume that you are referring to the UNIQUE
declaration in SQL. There is no similar mechanism, and IMHO that is a
feature. It should be handled in the domain model, otherwise you need to
bother the domain model with an infrastructure failure that is "expected".
3. I hope you have noticed that we separate Storage from Indexing/Query,
just like the world wide web. This also allows cross-store query, role-based
queries, and potentially asynchronous index updates.
For the client, we provide a simple fluent API for Query, which gets
translated to the plugged in Indexing engine in runtime (currently only
Sparql).
So,
UnitOfWork uow = unitofworkfactory.currentUnitOfWork();
QueryBuilder<Student> qb = querybuilderfactory.newQueryBuilder(
Student.class );
Student template = templateFor( Student.class );
Query<Student> q = qb.where( not( contains( template.courses(), givenCourse
) ) ).newQuery( uow );
// for paging...
q.firstResult( page*20 );
q.maxResults( 20 );
for( Student student : q )
{
}
(I hope I got all that right from memory)
The factories above are injected.
The eq(), contains() and not() are methods in QueryExpressions class.
IF you have a query that can't be expressed in this type-safe way, then you
can also request a Named Query, which is declared from start up in the
native query language installed.
HTH
Niclas
P.S. Hope you like what you see...
On 1 Dec 2009 21:46, "Eugene M. Hutorny" <[email protected]>
wrote:
Hello,
I have found your project while was looking for a solution for a good
concern separation. You project looks awesome!
I have some questions which I was not able to derive in my own.
1. You suggest using generics Property<T> to define properties in the
application domain model. It seems there is one issue with this approach,
which I would like to clarify. Because of the type erasure, the underlying
data type is not available during run-time. Therefore the persistener, when
loading an instance from the storage, probably would not be able to verify
if data loaded matches corresponding data types in the model (this could
happen because of code refactoring, for example) and, presumably, this will
lead to a class cast exception in the application code. Such kind of issues
will be difficult to debug, since the error detection place is way far from
the origin of the error. Is this a relevant issue?
2. How would you suggest creating a unique constraint on a field with your
persistence schema?
3. If my application needs to query for, let say, all students not attending
a given course, how this can be done with your persistence schema?
Kind regards,
Eugene
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
