M5 (B1?)

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

M5 (B1?)

Andrus Adamchik
While the M4 vote is still in progress, I went ahead and created a new version in Jira - 4.0.M5 - to commit the new code. I am actually hoping that M5 will be renamed to B1 at some point, and we can successfully fight the scope creep. Talking of which, here is what I'd like to see in Cayenne before the beta code freeze:

1. Cdbimport leftovers: track changes of auto increment status, column type status, etc.

2. Automatic module loading via ServiceLoader mechanism. We have lots of small modules now (eg. cayenne-java8). I want them to be included in ServerRuntime automatically with no explicit DI code.

3. Split cayenne-lifecycle into task-specific submodules. With #2 above this only makes sense.

4. API queries with GROUP BY / HAVING. This is a big one, and we have a huge PR waiting a review. I hope we can make this happen.

5. Java 8 "preference" for Modeler / cdbimport (making it easy to use "java.time" classes if you are on Java 8 instead of java.util.Date and friends)

6. A module providing JCacheQueryCache, integrating JCache (JSR 107). In addition to being a "standard", JCache can work as a proxy for most industrial check providers like EhCache, so we won't have to maintain our own providers for each one of them. (I already built JCacheQueryCache in Bootique. Will need to port it to Cayenne). Perhaps we also deprecate multiple cache groups support. None of the modern caches can effectively support more than one cache group per key. OSCache was the only exception, but OSCache is dead now.

7. Simplify DataChannelFilter. Split it into separate select and update filters, remove 'init' method (use injection instead).

8. DI improvements. Learned a lot about good DI patterns when writing Bootique. Want to apply this knowledge to Cayenne DI. We can easily add type-safe collection/map bindings API, as well as "contribution" API to simplify extensions.

9. Refresh Swing Modeler design (e.g. do the modern buttons).

10. Gradle support. Cayenne works with Gradle just fine, but we can provide some explicit facilities (or at least documentation on the best practices).

11. Review and deprecate older APIs, such as Query.getName(), Query.getDataMap().

The list is long (and keeps expanding). Though many of these items are negotiable and can be postponed until 4.1. Also most of the items are not that big. #4 is probably the biggest and the most invasive of all. I haven't included specific bug fixes. I assume those will happen at their "normal" pace.

Your list may be different, so please send your comments and offer your favorite items.

Andrus

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: M5 (B1?)

Andrus Adamchik

> On Dec 11, 2016, at 11:48 AM, Andrus Adamchik <[hidden email]> wrote:
>
> 2. Automatic module loading via ServiceLoader mechanism. We have lots of small modules now (eg. cayenne-java8). I want them to be included in ServerRuntime automatically with no explicit DI code.

I just committed an implementation for this one, so that we have the whole long release cycle to play with it. Works very nicely actually. The following modules are currently auto-loadable:

cayenne-crypto
cayenne-dbsync
cayenne-java8
cayenne-joda
cayenne-project
cayenne-server

Auto-loading library is provided by cayenne-di. But it has to be explicitly invoked. Currently only ServerRuntimeBuilder can do it. We will also need to integrate it in the ROP client and the Modeler (and build tools?), which may be a bit more challenging, as all of those depend on cayenne-server. Will likely require module structure refactoring.

Andrus
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: M5 (B1?)

Andrus Adamchik
In reply to this post by Andrus Adamchik
> 7. Simplify DataChannelFilter. Split it into separate select and update filters, remove 'init' method (use injection instead).

I think I might postpone this till after 4.0. At a closer look this may grow into a bigger task than I originally thought:

* It turned out that "init" method can be useful as we don't have any post-startup hooks in Cayenne DI. So it can be used as a kind of startup listener. Not ideal, but no replacement exists yet.

* Once the filter is split, "onSync" and "onQuery" become lambdas, and managing them via DI suddenly looks dirty. I'd rather we refactor to a more modern chainable stack, and allow to insert these interceptors anywhere between the stack stages, and in either global or query scopes. Which leads us to functional programming, monads and other good things (experimenting with those in LinkRest now [1]).

So certainly more invasive work than 4.0 should bear.

Andrus

[1] https://github.com/nhl/link-rest/issues/215


> On Dec 11, 2016, at 11:48 AM, Andrus Adamchik <[hidden email]> wrote:
>
> While the M4 vote is still in progress, I went ahead and created a new version in Jira - 4.0.M5 - to commit the new code. I am actually hoping that M5 will be renamed to B1 at some point, and we can successfully fight the scope creep. Talking of which, here is what I'd like to see in Cayenne before the beta code freeze:
>
> 1. Cdbimport leftovers: track changes of auto increment status, column type status, etc.
>
> 2. Automatic module loading via ServiceLoader mechanism. We have lots of small modules now (eg. cayenne-java8). I want them to be included in ServerRuntime automatically with no explicit DI code.
>
> 3. Split cayenne-lifecycle into task-specific submodules. With #2 above this only makes sense.
>
> 4. API queries with GROUP BY / HAVING. This is a big one, and we have a huge PR waiting a review. I hope we can make this happen.
>
> 5. Java 8 "preference" for Modeler / cdbimport (making it easy to use "java.time" classes if you are on Java 8 instead of java.util.Date and friends)
>
> 6. A module providing JCacheQueryCache, integrating JCache (JSR 107). In addition to being a "standard", JCache can work as a proxy for most industrial check providers like EhCache, so we won't have to maintain our own providers for each one of them. (I already built JCacheQueryCache in Bootique. Will need to port it to Cayenne). Perhaps we also deprecate multiple cache groups support. None of the modern caches can effectively support more than one cache group per key. OSCache was the only exception, but OSCache is dead now.
>
> 7. Simplify DataChannelFilter. Split it into separate select and update filters, remove 'init' method (use injection instead).
>
> 8. DI improvements. Learned a lot about good DI patterns when writing Bootique. Want to apply this knowledge to Cayenne DI. We can easily add type-safe collection/map bindings API, as well as "contribution" API to simplify extensions.
>
> 9. Refresh Swing Modeler design (e.g. do the modern buttons).
>
> 10. Gradle support. Cayenne works with Gradle just fine, but we can provide some explicit facilities (or at least documentation on the best practices).
>
> 11. Review and deprecate older APIs, such as Query.getName(), Query.getDataMap().
>
> The list is long (and keeps expanding). Though many of these items are negotiable and can be postponed until 4.1. Also most of the items are not that big. #4 is probably the biggest and the most invasive of all. I haven't included specific bug fixes. I assume those will happen at their "normal" pace.
>
> Your list may be different, so please send your comments and offer your favorite items.
>
> Andrus
>

Loading...