Mailing-List: contact dev-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cayenne.apache.org
From: Andrus Adamchik <andrus@objectstyle.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: M5 (B1?)
Date: Tue, 24 Jan 2017 18:00:49 +0300
References: <EB4D3C44-9CD6-4E1E-A8BB-D6E199535338@objectstyle.org>
To: dev@cayenne.apache.org
In-Reply-To: <EB4D3C44-9CD6-4E1E-A8BB-D6E199535338@objectstyle.org>
Message-Id: <0077AB81-F4FB-4F26-89C7-DDC84D04A9BD@objectstyle.org>
archived-at: Tue, 24 Jan 2017 15:00:56 -0000

> 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.=20

Andrus

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


> On Dec 11, 2016, at 11:48 AM, Andrus Adamchik <andrus@objectstyle.org> =
wrote:
>=20
> 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:
>=20
> 1. Cdbimport leftovers: track changes of auto increment status, column =
type status, etc.
>=20
> 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.
>=20
> 3. Split cayenne-lifecycle into task-specific submodules. With #2 =
above this only makes sense.
>=20
> 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.
>=20
> 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)
>=20
> 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.
>=20
> 7. Simplify DataChannelFilter. Split it into separate select and =
update filters, remove 'init' method (use injection instead).
>=20
> 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.=20
>=20
> 9. Refresh Swing Modeler design (e.g. do the modern buttons).=20
>=20
> 10. Gradle support. Cayenne works with Gradle just fine, but we can =
provide some explicit facilities (or at least documentation on the best =
practices).=20
>=20
> 11. Review and deprecate older APIs, such as Query.getName(), =
Query.getDataMap().
>=20
> 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.
>=20
> Your list may be different, so please send your comments and offer =
your favorite items.
>=20
> Andrus
>=20