> 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 <and...@objectstyle.org> 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 >
