polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Apache Polygene - Future Directions
Date Fri, 30 Dec 2016 17:24:16 GMT
For the question about "volunteer for Spring integration": *Roman!!!* Don't
you work for the Spring Framework guys???!?!?

On Fri, Dec 30, 2016 at 10:55 PM, Jiri Jetmar <juergen.jetmar@gmail.com>

> This are indeed valuable steps, but I fear that we can not follow the path
> to the required destination, as sooner or later we will deal with
> technical/infrastructural topics.

Once I was faced with keeping the getter/setter POJOs to back the Entity
system in Qi4j. It is isn't very hard to do for a specific case, but a
generic solution is rather hard. Perhaps some additional support can be
added to make this more straight forward (i.e. less advanced knowledge of
Polygene's capabilities.

>  Do you mean our Entity composites ?

I meant that you can declare that Habba<T> is my Property<T> class, Zoot<T>
is my Association<T> class and so on. That way, it can be seen as the pure
domain model is completely free of Polygene types (since we removed the
need for EntityComposite quite a long time ago by now).

Perhaps this can be abstracted in even better ways, so that getter/setter
types could be supported as Entity/Value types directly without
intermediary types, possibly using assembly face to declare what is what.

> Independently of that, I see the top-down approach regarding our data
> model as problematic. Means we are expressing the data model in a Polygene
> Application and "materialise" it to the underlying repository. Conceptually
> this is fine, very elegant, but the point it that data live (Data@Store)
> usually much longer then the application. Therefore there must be a way how
> to interface external data models.

This is probably a lot easier, if I understand what you are trying to get
at. Let's look at SQL DB as an example. Tables of rows with relationships
are fairly easy to model. One could even imagine a client tool where the
relations are described and that generates a Polygene model from it.
Ideally interactively (graphical even), but even a some description
language (SQL?) should be doable with a few weeks of focused work.

Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

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