Re: CAY-2842

[Andrus Adamchik]

Nikita might comment on whether this is a 5.0-only task. But I am with Michael 
on "var" in the framework. I use "var" declarations a lot in throwaway 
"scripting" code (usually data tasks with DFLib), but in any code that needs to 
be maintained, hiding variable types does complicate code review. That's been a 
source of frustration for me on various projects. And this is especially 
relevant for Cayenne where you want the code to be clear and readable.

Cheers,
Andrus

> On Mar 7, 2024, at 5:52 PM, Michael Gentry  wrote:
> 
> Just noticed this merge:
> 
> https://github.com/apache/cayenne/pull/605/commits/99138fbcfe8f23e67805557bfcbca5bb452d8325
> 
> I noticed there are several "var" variables, such as:
> 
>var orderDbAttribute = getOrderDbAttribute(nodeBuilder.build());
> 
> These won't compile with JDK 8 (introduced in 10). Did the minimum JDK
> change to something higher? The documentation says: Cayenne 4.2 requires
> JDK 1.8 or newer. Looks like 5.x will require JDK 11, so perhaps that's
> what this is about?
> 
> If it is JDK 11+, do we want to allow "var" in the codebase? Makes it
> harder to do code reviews (IMHO).
> 
> Thanks,
> mrg

Re: Web Site / Documentation

[Andrus Adamchik]

Hi Mike, 

Thanks for mentioning. There are probably other places across the documentation 
that may need some love. E.g. working with custom functions. I guess whoever 
gets to it first, wins :)

Thanks,
Andrus


> On Jan 10, 2024, at 9:53 AM, Michael Gentry  wrote:
> 
> Hi,
> 
> In trying to help Riccardo, I noticed the big "DOCUMENTATION" link in the
> header of the web site goes to the 4.1 documentation and not the 4.2
> documentation. Also, the validateForX methods are barely mentioned and
> otherwise undocumented. Also also, the system requirements table needs
> updated here:
> https://cayenne.apache.org/docs/4.2/cayenne-guide/#system-requirements
> 
> There are probably more, but that's what I noticed offhand. I'll try to fix
> them when I have some time, but it might be a while.
> 
> Thanks,
> mrg

Re: Cayenne 5.0 proposals

[Andrus Adamchik]

Let's discuss what we can improve, and then see the impact. 

FWIW, we have both DataObject and Persistent. "Persistent" seems ok, and we can 
get rid of DataObject. 

ObjectContext is a "context" :) (i.e. an isolated scope). PersistentContext 
maybe?

Andrus


> On Nov 22, 2023, at 8:46 AM, Michael Gentry  wrote:
> 
> In that case, I'd like to throw out my nomination for a class/name change...
> 
> ObjectContext (and I guess BaseContext)
> 
> The words "object" and "context" don't really provide a new user or someone
> maintaining an app with any idea what they do. I guess I'd also add "data"
> to that list (such as in DataObject -- what exactly is this?). The word
> "base" is a bit better since it seems to imply the top-level "context"
> (whatever that is). I know when I was teaching new developers on Cayenne
> projects this naming kind of caused their eyes to glaze over for a bit. I'd
> mainly have to wavy-hands them and tell them "just remember you need an
> ObjectContext to..."
> 
> Before spitballing new names, what are thoughts/feelings on this? Yes, it
> would be a lot of global search/replace, but probably not too much effort
> outside of that. (Use a shell script to automate that task in the code and
> docs, but the docs might need a bit more polishing.)
> 
> Thanks
> mrg
> 
> 
> On Wed, Nov 22, 2023 at 7:18 AM Andrus Adamchik  wrote:
> 
>> I think there's going to be quite a few. Since we got rid of ROP, we can
>> tighten our naming everywhere - modules, packages, classes.
>> 
>> Andrus
>> 
>> 
>> 
>>> On Nov 22, 2023, at 8:07 AM, Michael Gentry  wrote:
>>> 
>>> Hi Nikita!
>>> 
>>> Both sound very reasonable to me, so +1 for that.
>>> 
>>> Will there be any backward-compatibility breaking changes in 5.x?
>>> 
>>> Thanks,
>>> mrg
>>> 
>>> 
>>> On Tue, Nov 21, 2023 at 3:04 AM Nikita Timofeev <
>> ntimof...@objectstyle.com>
>>> wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> Wanted to share a couple of my thoughts about changes that could be good
>>>> for Cayenne. And the first milestone release of Cayenne 5.0 could be a
>>>> perfect target for these changes.
>>>> 
>>>> 1. Get rid of the `server` part in the names everywhere, starting by
>>>> renaming our core dependency from `cayenne-server` to just `cayenne`.
>>>> As we already removed the `client` counterpart, `server` just doesn't
>> make
>>>> sense anymore.
>>>> 
>>>> 2. Change of the versioning schema we use for the development cycle. A
>>>> short version of the proposal: drop BETA versions, keep the version of
>>>> snapshot build always the same, and slightly change format to articulate
>>>> what is the actual version.
>>>> 
>>>> Format would look like `MAJOR.MINOR-QUALIFIER`. Where the qualifier is
>> one
>>>> of `SNAPSHOT`, `M` for the milestone or `RC` for the release candidate.
>>>> 
>>>> Example for the 5.0:
>>>> - snapshot always stays as 5.0-SNAPSHOT
>>>> - milestones releases are 5.0-M1, 5.0-M2 etc.
>>>> - release candidates are 5.0-RC1, 5.0-RC2, etc.
>>>> - and final release is just 5.0
>>>> 
>>>> And here's a reason for that change. It solves two minor problems with
>> the
>>>> current schema. The first one is that all systems think that `B` goes
>>>> before `M`, so our beta versions always look older than milestones. We
>> are
>>>> not that strict about what is beta nor are we enforcing any rules, so
>> there
>>>> should be no problems with that.
>>>> The second one is that projects using SNAPSHOT versions should update
>>>> dependency every time we make a dev release. Again not a big change and
>>>> should not affect anything really, as there shouldn't be many projects
>>>> brave enough to just use SNAPSHOT.
>>>> 
>>>> Note this change does not affect overall versioning, e.g. patch versions
>>>> like 5.0.1 or global updates like 5.1.
>>>> 
>>>> 
>>>> --
>>>> Best regards,
>>>> Nikita Timofeev
>>>> 
>> 
>> 

Re: Cayenne 5.0 proposals

[Andrus Adamchik]

I think there's going to be quite a few. Since we got rid of ROP, we can 
tighten our naming everywhere - modules, packages, classes.

Andrus



> On Nov 22, 2023, at 8:07 AM, Michael Gentry  wrote:
> 
> Hi Nikita!
> 
> Both sound very reasonable to me, so +1 for that.
> 
> Will there be any backward-compatibility breaking changes in 5.x?
> 
> Thanks,
> mrg
> 
> 
> On Tue, Nov 21, 2023 at 3:04 AM Nikita Timofeev 
> wrote:
> 
>> Hi all,
>> 
>> Wanted to share a couple of my thoughts about changes that could be good
>> for Cayenne. And the first milestone release of Cayenne 5.0 could be a
>> perfect target for these changes.
>> 
>> 1. Get rid of the `server` part in the names everywhere, starting by
>> renaming our core dependency from `cayenne-server` to just `cayenne`.
>> As we already removed the `client` counterpart, `server` just doesn't make
>> sense anymore.
>> 
>> 2. Change of the versioning schema we use for the development cycle. A
>> short version of the proposal: drop BETA versions, keep the version of
>> snapshot build always the same, and slightly change format to articulate
>> what is the actual version.
>> 
>> Format would look like `MAJOR.MINOR-QUALIFIER`. Where the qualifier is one
>> of `SNAPSHOT`, `M` for the milestone or `RC` for the release candidate.
>> 
>> Example for the 5.0:
>> - snapshot always stays as 5.0-SNAPSHOT
>> - milestones releases are 5.0-M1, 5.0-M2 etc.
>> - release candidates are 5.0-RC1, 5.0-RC2, etc.
>> - and final release is just 5.0
>> 
>> And here's a reason for that change. It solves two minor problems with the
>> current schema. The first one is that all systems think that `B` goes
>> before `M`, so our beta versions always look older than milestones. We are
>> not that strict about what is beta nor are we enforcing any rules, so there
>> should be no problems with that.
>> The second one is that projects using SNAPSHOT versions should update
>> dependency every time we make a dev release. Again not a big change and
>> should not affect anything really, as there shouldn't be many projects
>> brave enough to just use SNAPSHOT.
>> 
>> Note this change does not affect overall versioning, e.g. patch versions
>> like 5.0.1 or global updates like 5.1.
>> 
>> 
>> --
>> Best regards,
>> Nikita Timofeev
>> 

Re: Cayenne 5.0 proposals

[Andrus Adamchik]

I am +1 on both.

> On Nov 21, 2023, at 4:04 AM, Nikita Timofeev  
> wrote:
> 
> Hi all,
> 
> Wanted to share a couple of my thoughts about changes that could be good
> for Cayenne. And the first milestone release of Cayenne 5.0 could be a
> perfect target for these changes.
> 
> 1. Get rid of the `server` part in the names everywhere, starting by
> renaming our core dependency from `cayenne-server` to just `cayenne`.
> As we already removed the `client` counterpart, `server` just doesn't make
> sense anymore.
> 
> 2. Change of the versioning schema we use for the development cycle. A
> short version of the proposal: drop BETA versions, keep the version of
> snapshot build always the same, and slightly change format to articulate
> what is the actual version.
> 
> Format would look like `MAJOR.MINOR-QUALIFIER`. Where the qualifier is one
> of `SNAPSHOT`, `M` for the milestone or `RC` for the release candidate.
> 
> Example for the 5.0:
> - snapshot always stays as 5.0-SNAPSHOT
> - milestones releases are 5.0-M1, 5.0-M2 etc.
> - release candidates are 5.0-RC1, 5.0-RC2, etc.
> - and final release is just 5.0
> 
> And here's a reason for that change. It solves two minor problems with the
> current schema. The first one is that all systems think that `B` goes
> before `M`, so our beta versions always look older than milestones. We are
> not that strict about what is beta nor are we enforcing any rules, so there
> should be no problems with that.
> The second one is that projects using SNAPSHOT versions should update
> dependency every time we make a dev release. Again not a big change and
> should not affect anything really, as there shouldn't be many projects
> brave enough to just use SNAPSHOT.
> 
> Note this change does not affect overall versioning, e.g. patch versions
> like 5.0.1 or global updates like 5.1.
> 
> 
> -- 
> Best regards,
> Nikita Timofeev

Re: [GitHub] [cayenne-website] andrus closed pull request #21: Update cayenne-guide.html minor text edits lines 461-1000

[Andrus Adamchik]

See my other message:


> Ah, found the answer - GitHub and Apache Gitbox accounts need to be linked to 
> get the needed permissions. So I followed the instructions here: 
> https://infra.apache.org/apache-github.html , waited for 5 min, refreshed 
> GitHub, and now I see the "Close" button.




> On Sep 24, 2023, at 9:03 PM, Michael Gentry  wrote:
> 
> Looks like you got it closed. What was the magic?
> 
> 
> On Sun, Sep 24, 2023 at 7:28 AM andrus (via GitHub)  wrote:
> 
>> 
>> andrus closed pull request #21: Update cayenne-guide.html minor text edits
>> lines 461-1000
>> URL: https://github.com/apache/cayenne-website/pull/21
>> 
>> 
>> --
>> This is an automated message from the Apache Git Service.
>> To respond to the message, please log on to GitHub and use the
>> URL above to go to the specific comment.
>> 
>> To unsubscribe, e-mail: dev-unsubscr...@cayenne.apache.org
>> 
>> For queries about this service, please contact Infrastructure at:
>> us...@infra.apache.org
>> 
>> 

Re: Closing Github PRs without merging

[Andrus Adamchik]

Ah, found the answer - GitHub and Apache Gitbox accounts need to be linked to 
get the needed permissions. So I followed the instructions here: 
https://infra.apache.org/apache-github.html , waited for 5 min, refreshed 
GitHub, and now I see the "Close" button.

Andrus


> On Sep 23, 2023, at 11:14 AM, Michael Gentry  wrote:
> 
> I'm not seeing it, either. Perhaps a permissions issue?
> 
> On Sat, Sep 23, 2023 at 8:45 AM Andrus Adamchik  wrote:
> 
>> Hey, anyone knows how to manually close pull requests on GitHub (without
>> merging)? Specifically talking about this one that is no longer relevant:
>> 
>> https://github.com/apache/cayenne-website/pull/21
>> 
>> I only see the "Comment" button. No "Close"
>> 
>> Andrus

Closing Github PRs without merging

[Andrus Adamchik]

Hey, anyone knows how to manually close pull requests on GitHub (without 
merging)? Specifically talking about this one that is no longer relevant:

https://github.com/apache/cayenne-website/pull/21

I only see the "Comment" button. No "Close"

Andrus

Re: [VOTE] Apache Cayenne 4.2 release

[Andrus Adamchik]

Congrats everyone! It's been a long road (3 years since the first 4.2 
milestone) and the result is great - mature DB Import, reworked stack that 
allows custom SQL generators, etc., etc.

I will prepare announcements.

Andrus

> On May 25, 2023, at 5:03 PM, Nikita Timofeev  
> wrote:
> 
> With my +1 vote the result is following:
> 
> John Huss (PMC): +1
> Andrus Adamchik (PMC): +1
> Nikita Timofeev (PMC): +1
> 
> I will finish this release soon.
> Thanks everyone!
> 
> 
> On Sat, May 20, 2023 at 11:17 AM Andrus Adamchik  wrote:
>> 
>> Very excited to have 4.2 out, especially with those regressions in RC2. My 
>> checklist passes, I am +1.
>> 
>> + MD5/SHA512 matches
>> + Signature checks
>> + rat passes
>> + builds from source
>> + Modeler runs on OS X
>> + Cross-platform Modeler runs on OS X
>> + Upgrade Agrest using the Maven repo.
>> + Upgrade LinkMove using the Maven repo.
>> 
>> Andrus
>> 
>> 
>>> On May 16, 2023, at 1:42 PM, Nikita Timofeev  
>>> wrote:
>>> 
>>> Hi all,
>>> 
>>> The 4.2 GA version is finally here.
>>> This release contains some important fixes for issues found in RC2.
>>> 
>>> Release notes: https://github.com/apache/cayenne/blob/4.2/RELEASE-NOTES.txt
>>> Maven repo: 
>>> https://repository.apache.org/content/repositories/orgapachecayenne-1052/
>>> Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.2/
>>> 
>>> Please evaluate and cast your votes
>>> 
>>> --
>>> Best regards,
>>> Nikita Timofeev
>> 
> 
> 
> --
> Best regards,
> Nikita Timofeev

Re: [VOTE] Apache Cayenne 4.2 release

[Andrus Adamchik]

Very excited to have 4.2 out, especially with those regressions in RC2. My 
checklist passes, I am +1.

+ MD5/SHA512 matches
+ Signature checks
+ rat passes
+ builds from source
+ Modeler runs on OS X
+ Cross-platform Modeler runs on OS X
+ Upgrade Agrest using the Maven repo.
+ Upgrade LinkMove using the Maven repo.

Andrus


> On May 16, 2023, at 1:42 PM, Nikita Timofeev  
> wrote:
> 
> Hi all,
> 
> The 4.2 GA version is finally here.
> This release contains some important fixes for issues found in RC2.
> 
> Release notes: https://github.com/apache/cayenne/blob/4.2/RELEASE-NOTES.txt
> Maven repo: 
> https://repository.apache.org/content/repositories/orgapachecayenne-1052/
> Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.2/
> 
> Please evaluate and cast your votes
> 
> -- 
> Best regards,
> Nikita Timofeev

Re: [VOTE] Apache Cayenne 4.0.3 release

[Andrus Adamchik]

Java 17 probably. I was using Java 8 for the local build. 

> On Feb 19, 2023, at 7:38 PM, Michael Gentry  wrote:
> 
> I'm seeing errors when building:
> 
> [mrg@odin 13:31:49] ~/Projects/Cayenne-Release/cayenne-4.0.3-src > mvn
> clean verify -Passembly,src,generic,mac
> [INFO] Scanning for projects...
> [INFO]
> 
> ...
> [ERROR] Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> 0.001 s <<< FAILURE! - in
> org.apache.cayenne.remote.hessian.HessianConfigTest
> [ERROR]
> testLoadFactoryNoExtensions(org.apache.cayenne.remote.hessian.HessianConfigTest)
> Time elapsed: 0 s  <<< ERROR!
> java.lang.NoClassDefFoundError: Could not initialize class
> com.caucho.hessian.io.ContextSerializerFactory
> at
> org.apache.cayenne.remote.hessian.HessianConfigTest.testLoadFactoryNoExtensions(HessianConfigTest.java:36)
> ...
> [ERROR] Errors:
> [ERROR]   ROPServletTest.testInitHessianService:174 » NoClassDefFound Could
> not initiali...
> [ERROR]   ROPServletTest.testInitWithExtraModules:142 »
> ExceptionInInitializer
> [ERROR]   ROPServletTest.testInitWithLocation:88 » NoClassDefFound Could
> not initialize ...
> [ERROR]   ROPServletTest.testInitWithServletName:66 » NoClassDefFound Could
> not initiali...
> [ERROR]   ROPServletTest.testInitWithStandardModules:110 » NoClassDefFound
> Could not ini...
> [ERROR]   HessianConfigTest.testLoadFactoryNoExtensions:36 »
> NoClassDefFound Could not i...
> [ERROR] Tests run: 985, Failures: 0, Errors: 6, Skipped: 0
> 
> It has been ages since I built 4.0, though, so I'm probably doing it
> wrongly.
> 
> [mrg@odin 13:33:59] ~/Projects/Cayenne-Release/cayenne-4.0.3-src > mvn -v
> Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /usr/local/Cellar/maven/3.9.0/libexec
> Java version: 17.0.6, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@17/17.0.6/libexec/openjdk.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "13.1", arch: "x86_64", family: "mac"
> 
> Thoughts?
> 
> On Tue, Feb 14, 2023 at 6:08 AM Nikita Timofeev 
> wrote:
> 
>> Hi all,
>> 
>> Here is the 4.0.3 release that just adds JDK 17 support in the Modeler.
>> 
>> Release notes:
>> https://github.com/apache/cayenne/blob/4.0.3/RELEASE-NOTES.txt
>> Maven repo:
>> https://repository.apache.org/content/repositories/orgapachecayenne-1057/
>> Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.0.3/
>> 
>> Please evaluate and cast your votes
>> 
>> --
>> Best regards,
>> Nikita Timofeev
>> 

Re: [VOTE] Apache Cayenne 4.0.3 release

[Andrus Adamchik]

4.0 is old, but there's still a significant number of apps using it, and the 
4.0 Modeler would not start if you have Java 17 on your desktop. So this 
release would unblock quite a few users. I just verified it, everything looks 
good. 

+ MD5/SHA512 matches
+ Signature checks
+ rat passes
+ builds from source
+ Modeler runs on OS X
+ Cross-platform Modeler runs on OS X
+ Upgrade LinkMove using the Maven repo.

The Maven repo link below has a typo. It should be 
https://repository.apache.org/content/repositories/orgapachecayenne-1051/ . The 
repo itself is fine though.

So I am +1.

Cheers,
Andrus


> On Feb 14, 2023, at 12:07 PM, Nikita Timofeev  
> wrote:
> 
> Hi all,
> 
> Here is the 4.0.3 release that just adds JDK 17 support in the Modeler.
> 
> Release notes: https://github.com/apache/cayenne/blob/4.0.3/RELEASE-NOTES.txt
> Maven repo: 
> https://repository.apache.org/content/repositories/orgapachecayenne-1057/
> Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.0.3/
> 
> Please evaluate and cast your votes
> 
> -- 
> Best regards,
> Nikita Timofeev

Re: [VOTE] Apache Cayenne 4.2.RC2 release

[Andrus Adamchik]

Congrats! 

Being involved in investigating some of the latest issues fixed in this 
release, I am pretty confident the next one can be a GA release.

Andrus

> On Dec 5, 2022, at 8:13 AM, Nikita Timofeev  wrote:
> 
> With my +1 the result is following:
> 
> Andrus Adamchik (PMC): +1
> John Huss (PMC): +1
> Michael Gentry (PMC): +1
> Nikita Timofeev (PMC): +1
> 
> I will finish this release today.
> Thanks everyone!
> 
> 
> On Fri, Dec 2, 2022 at 10:02 PM Michael Gentry  wrote:
>> 
>> Checksums: OK
>> Signatures: OK
>> RAT: OK
>> Cayenne Modeler: OK (didn't test extensively, but looked alright under Java
>> 19)
>> Java 8/17 Source Build: OK (unit tests pass, etc)
>> 
>> +1 for release.
>> 
>> Thanks Nikita!
>> 
>> 
>> On Thu, Dec 1, 2022 at 5:48 AM Nikita Timofeev 
>> wrote:
>> 
>>> Hi all,
>>> 
>>> Here's a 4.2.RC2 release.
>>> 
>>> It has couple minor fixes that better be tested a bit, so it's next
>>> RC. Hope it could be the last before the GA release.
>>> 
>>> Release notes:
>>> https://github.com/apache/cayenne/blob/4.2.RC2/RELEASE-NOTES.txt
>>> Maven repo:
>>> https://repository.apache.org/content/repositories/orgapachecayenne-1050/
>>> Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.2.RC2/
>>> 
>>> Please evaluate and cast your votes.
>>> 
>>> --
>>> Best regards,
>>> Nikita Timofeev
>>> 
> 
> 
> 
> --
> Best regards,
> Nikita Timofeev

Re: [VOTE] Apache Cayenne 4.2.RC2 release

[Andrus Adamchik]

And since my work depends on some of these bug fixes, I just did a quick 
evaluation:

 + MD5/SHA512 matches (using cayenne-release-tools script)
 + Signature checks (using cayenne-release-tools script)
 + rat passes
 + builds from source
 + Modeler runs on OS X
 + Cross-platform Modeler runs on OS X
 + Upgrade AgRest/LinkMove using the Maven repo.

Everything looks good. I am +1.

Andrus


> On Dec 1, 2022, at 11:47 AM, Nikita Timofeev  
> wrote:
> 
> Hi all,
> 
> Here's a 4.2.RC2 release.
> 
> It has couple minor fixes that better be tested a bit, so it's next
> RC. Hope it could be the last before the GA release.
> 
> Release notes: 
> https://github.com/apache/cayenne/blob/4.2.RC2/RELEASE-NOTES.txt
> Maven repo: 
> https://repository.apache.org/content/repositories/orgapachecayenne-1050/
> Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.2.RC2/
> 
> Please evaluate and cast your votes.
> 
> -- 
> Best regards,
> Nikita Timofeev

Re: CayenneModeler on MacOS Ventura

[Andrus Adamchik]

Thanks for confirming. I like bugs that fix themselves :) 

> On Nov 29, 2022, at 8:17 PM, Lon Varscsak  wrote:
> 
> Yes, it appears to be working now.
> 
> On Tue, Nov 22, 2022 at 8:55 AM Andrus Adamchik  wrote:
> 
>> Hey Lon,
>> 
>> So after I installed the latest Ventura update (13.0.1), this problem is
>> gone. Did it fix it for you as well?
>> 
>> Andrus
>> 
>> 
>>> On Nov 15, 2022, at 10:02 PM, Lon Varscsak 
>> wrote:
>>> 
>>> Yes, I have this issue as well on Ventura, but am using an Intel iMac.
>>> 
>>> On Tue, Nov 8, 2022 at 1:08 AM Andrus Adamchik 
>> wrote:
>>> 
>>>> Hi Mike, thanks for checking. Yeah, too many variables. I suspected
>>>> Ventura, as it worked for me prior to the OS upgrade on the same
>> machine.
>>>> But I don't have anything more concrete. I suppose I may try to debug
>> the
>>>> source code.
>>>> 
>>>> Andrus
>>>> 
>>>>> On Nov 8, 2022, at 9:00 AM, Michael Gentry 
>> wrote:
>>>>> 
>>>>> I did a quick test and it works on Ventura for me. MBP i7 with Java 19.
>>>>> 
>>>>> I see in the ticket you mention M1. Could this be a Java on M1 issue?
>> Or
>>>>> even Java 17?
>>>>> 
>>>>> On Mon, Nov 7, 2022 at 7:22 AM Andrus Adamchik 
>>>> wrote:
>>>>> 
>>>>>> https://issues.apache.org/jira/browse/CAY-2770
>>>>>> 
>>>>>> Anyone else noticed issues like this on MacOS Ventura? It is quite
>>>>>> annoying and Google didn't reveal anything relevant. FWIW, after the
>>>>>> Ventura upgrade I am having issues with IntelliJ IDEA as well. It
>>>>>> periodically becomes unresponsive. Certain mouse and keyboard actions
>>>>>> freeze and require a restart.
>>>>>> 
>>>>>> Andrus
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>> 
>> 

Re: CayenneModeler on MacOS Ventura

[Andrus Adamchik]

Hey Lon,

So after I installed the latest Ventura update (13.0.1), this problem is gone. 
Did it fix it for you as well?

Andrus


> On Nov 15, 2022, at 10:02 PM, Lon Varscsak  wrote:
> 
> Yes, I have this issue as well on Ventura, but am using an Intel iMac.
> 
> On Tue, Nov 8, 2022 at 1:08 AM Andrus Adamchik  wrote:
> 
>> Hi Mike, thanks for checking. Yeah, too many variables. I suspected
>> Ventura, as it worked for me prior to the OS upgrade on the same machine.
>> But I don't have anything more concrete. I suppose I may try to debug the
>> source code.
>> 
>> Andrus
>> 
>>> On Nov 8, 2022, at 9:00 AM, Michael Gentry  wrote:
>>> 
>>> I did a quick test and it works on Ventura for me. MBP i7 with Java 19.
>>> 
>>> I see in the ticket you mention M1. Could this be a Java on M1 issue? Or
>>> even Java 17?
>>> 
>>> On Mon, Nov 7, 2022 at 7:22 AM Andrus Adamchik 
>> wrote:
>>> 
>>>> https://issues.apache.org/jira/browse/CAY-2770
>>>> 
>>>> Anyone else noticed issues like this on MacOS Ventura? It is quite
>>>> annoying and Google didn't reveal anything relevant. FWIW, after the
>>>> Ventura upgrade I am having issues with IntelliJ IDEA as well. It
>>>> periodically becomes unresponsive. Certain mouse and keyboard actions
>>>> freeze and require a restart.
>>>> 
>>>> Andrus
>>>> 
>>>> 
>> 
>> 

Shutting down maven.objectstyle.org/nexus

[Andrus Adamchik]

I am going to shut down the Nexus instance at 
https://maven.objectstyle.org/nexus/ .  There's so much open source 
infrastructure out there, that running your own Maven repo seems wasteful, and 
what's worse it creates security issues without proper maintenance.

This server was used for Cayenne builds, as a virtual repo combining Maven 
Central and an internal repo with artifacts that are not available on Central. 
Cayenne 5.0 no longer requires that second part, and for the earlier versions I 
placed those artifacts in a static directory under Apache at 
https://maven.objectstyle.org/repos/cayenne-deps/ . 

So Nexus is going down now.

Andrus

4.3 -> 5.0

[Andrus Adamchik]

I suggest we switch master to "5.0" release. Some big changes are anticipated 
to go in this release, so it warrants a major version increase. 

Andrus

Re: CayenneModeler on MacOS Ventura

[Andrus Adamchik]

Hi Mike, thanks for checking. Yeah, too many variables. I suspected Ventura, as 
it worked for me prior to the OS upgrade on the same machine. But I don't have 
anything more concrete. I suppose I may try to debug the source code.

Andrus

> On Nov 8, 2022, at 9:00 AM, Michael Gentry  wrote:
> 
> I did a quick test and it works on Ventura for me. MBP i7 with Java 19.
> 
> I see in the ticket you mention M1. Could this be a Java on M1 issue? Or
> even Java 17?
> 
> On Mon, Nov 7, 2022 at 7:22 AM Andrus Adamchik  wrote:
> 
>> https://issues.apache.org/jira/browse/CAY-2770
>> 
>> Anyone else noticed issues like this on MacOS Ventura? It is quite
>> annoying and Google didn't reveal anything relevant. FWIW, after the
>> Ventura upgrade I am having issues with IntelliJ IDEA as well. It
>> periodically becomes unresponsive. Certain mouse and keyboard actions
>> freeze and require a restart.
>> 
>> Andrus
>> 
>> 

CayenneModeler on MacOS Ventura

[Andrus Adamchik]

https://issues.apache.org/jira/browse/CAY-2770

Anyone else noticed issues like this on MacOS Ventura? It is quite annoying and 
Google didn't reveal anything relevant. FWIW, after the Ventura upgrade I am 
having issues with IntelliJ IDEA as well. It periodically becomes unresponsive. 
Certain mouse and keyboard actions freeze and require a restart. 

Andrus

Re: Ant and eclipse related things in the pom.xml

[Andrus Adamchik]

> On Aug 1, 2022, at 5:19 PM, Mike Kienenberger  wrote:
> 
> Unfortunately, my most "up-to-date" cayenne project uses 3.x and it is
> likely being replaced at the end of the year, which is why I haven't
> commented much on Cayenne 5.0.

I remember, you mentioned it before. This is sad. 

FWIW, we have other orgs migrating their whole codebases *to* Cayenne and also 
looking at Agrest.io on top of it. So maybe the management needs a fresh pitch? 
:) Anyways, I am kidding. I am sure it was a conscious decision. It is what it 
is.

Andrus

Re: Ant and eclipse related things in the pom.xml

[Andrus Adamchik]

Thanks, Mike! That makes it easy :)

>  If it's important to me or to someone else in the
> future, we can look into adding it back, but there are probably easier
> ways to do these things these days.

I agree.

Andrus

> On Aug 1, 2022, at 5:19 PM, Mike Kienenberger  wrote:
> 
> Was I the culprit?   I guess I might have been.
> 
> It's only used to provide ant support to injecting dependencies into
> velocity templates, if I recall correctly.
> 
> I'd say drop it.   If it's important to me or to someone else in the
> future, we can look into adding it back, but there are probably easier
> ways to do these things these days.
> 
> Unfortunately, my most "up-to-date" cayenne project uses 3.x and it is
> likely being replaced at the end of the year, which is why I haven't
> commented much on Cayenne 5.0.
> 
> On Mon, Aug 1, 2022 at 3:22 AM Andrus Adamchik  wrote:
>> 
>> 
>>> On Jul 28, 2022, at 1:44 PM, Nikita Timofeev  
>>> wrote:
>>> 
>>> 1. Ant and vpp dependency. This one is really the last that prevents
>>> us from switching to the Maven Central repo instead of the custom one
>>> we are using, I want to change a bit this feature and use reflection
>>> to get rid of compile-time dependency. Is there anything I need to
>>> worry about?
>> 
>> IIRC, Mike Kienenberger used (and contributed to) VPP integration. Mike, 
>> maybe you have any comments? Is this something you'd still use in the future 
>> Cayenne 5.0?
>> 
>> Andrus
>> 
>> 

Re: Ant and eclipse related things in the pom.xml

[Andrus Adamchik]

> On Jul 28, 2022, at 1:44 PM, Nikita Timofeev  
> wrote:
> 
> 1. Ant and vpp dependency. This one is really the last that prevents
> us from switching to the Maven Central repo instead of the custom one
> we are using, I want to change a bit this feature and use reflection
> to get rid of compile-time dependency. Is there anything I need to
> worry about?

IIRC, Mike Kienenberger used (and contributed to) VPP integration. Mike, maybe 
you have any comments? Is this something you'd still use in the future Cayenne 
5.0?

Andrus

Re: Cayenne 5.0 - getting rid of legacy

[Andrus Adamchik]

> On Jul 5, 2022, at 2:00 PM, Nikita Timofeev  wrote:
> 
> - requiring JDK 17 version may limit adoption, as I believe there are
> many projects that can't update to Java 17 yet and there are no
> immediate benefits that I could see for Cayenne (though I like the
> idea of using fresh Java).
> But upgrading to 11 could be good as it will allow to drop some ugly
> hacks at least in the Modeler.

BTW, here is a bigger poll done by the Maven folks on Twitter:

https://twitter.com/khmarbaise/status/1549429653202518016

As of this writing it has the following vote breakdown:

* JDK 8 - 15%
* JDK 11 - 36%
* JDK 17 - 46%

Kinda tells me that the new Bootique could be on 17, while the new Cayenne 
still has to stay on 11 as Nikita suggested. The difference betyween the two is 
that Bootique brings most of the app dependencies with it, so it can drive (and 
simplify) the upgrade for an entire app. While Cayenne needs to work with what 
a user has.

On the other hand, ~ a year from now when 5.x may become stable, the numbers 
are going to be different...

Andrus

Re: Query API suggestions

[Andrus Adamchik]

Yeah, we should. May need to split the UI for SQLSelect and SQLExec in the 
Modeler into 2 separate queries.

> On Jul 18, 2022, at 4:37 PM, John Huss  wrote:
> 
> Sounds good. For #3 on SQLTemplate, will these still be able to be defined
> in the modeler? I like being able to do that, though I only use a single
> database target for the SQL.
> 
> On Fri, Jul 15, 2022 at 2:40 PM Andrus Adamchik  wrote:
> 
>> Another block of ideas for 5.0. Related to expressions and queries...
>> 
>> 0. Terse and consistent Expression API. 90% of expressions are done with
>> Properties now, but the remaining 10% are clunky and inconsistent. I am
>> thinking the main class (interface) should be called "Exp", combining
>> static methods from ExpressionFactory and common instance methods from
>> Expression. The API itself needs to be reworked for fluency and readability
>> (e.g. no "Exp" suffix in methods like "andExp()", etc.), and should be
>> aligned with the more modern Property API (e.g. "eq" instead of "matchExp").
>> 
>> 1. Merge EJBQLQuery into ObjectSelect. I think we already have the
>> machinery to implement all features of EJBQLQuery (such as subqueries,
>> EXISTS, etc.) in ObjectSelect. So let's do that, and then create a parser
>> (based on the old EJBQL parser, but more Cayenne-centric) to parse
>> ObjectSelects from Strings. Remove EJBQLQuery, and all the ugliness needed
>> to support its execution.
>> 
>> 2. SelectById query is redundant. It can be deprecated and replaced with a
>> special expression applied to ObjectSelect. With the new Exp API this may
>> look like this:
>> 
>>  ObjectSelect.query(MyEntity.class).where(Exp.byId(5));
>> 
>> On top of that we can probably do something via generated Properties.
>> 
>> 3. SQLTemplate should be deprecated. SQLExec (and partially - SQLSelect)
>> replaces it. One feature that SQLTemplate supported is multiple sets of
>> PreparedStatement parameters ("batches"), that we can potentially port to
>> SQLExec.
>> 
>> 4. Replace QueryResponse with QueryResult. Same thing, better API. Keeping
>> them both is redundant.
>> 
>> 5. "statementFetchSize" should be fully integrated. Currently it has no
>> effect on MySQL, without somehow manually setting a few extra Statement
>> parameters [1] :
>> 
>>conn.createStatement(ResultSet.TYPE_FORWARD_ONLY,
>> ResultSet.CONCUR_READ_ONLY);
>> 
>> Cayenne should take care of it, allowing the users to process large
>> cursors [2].
>> 
>> 6. "timeout(long,TimeUnit)" - should result in setting Statement timeout.
>> Need to test how well it works on different DBs.
>> 
>> Andrus
>> 
>> 
>> [1]
>> https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-implementation-notes.html
>> <
>> https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-implementation-notes.html
>>> 
>> [2] https://github.com/nhl/link-move/issues/142

Query API suggestions

[Andrus Adamchik]

Another block of ideas for 5.0. Related to expressions and queries...

0. Terse and consistent Expression API. 90% of expressions are done with 
Properties now, but the remaining 10% are clunky and inconsistent. I am 
thinking the main class (interface) should be called "Exp", combining static 
methods from ExpressionFactory and common instance methods from Expression. The 
API itself needs to be reworked for fluency and readability (e.g. no "Exp" 
suffix in methods like "andExp()", etc.), and should be aligned with the more 
modern Property API (e.g. "eq" instead of "matchExp").

1. Merge EJBQLQuery into ObjectSelect. I think we already have the machinery to 
implement all features of EJBQLQuery (such as subqueries, EXISTS, etc.) in 
ObjectSelect. So let's do that, and then create a parser (based on the old 
EJBQL parser, but more Cayenne-centric) to parse ObjectSelects from Strings. 
Remove EJBQLQuery, and all the ugliness needed to support its execution.

2. SelectById query is redundant. It can be deprecated and replaced with a 
special expression applied to ObjectSelect. With the new Exp API this may look 
like this: 

  ObjectSelect.query(MyEntity.class).where(Exp.byId(5));

On top of that we can probably do something via generated Properties.

3. SQLTemplate should be deprecated. SQLExec (and partially - SQLSelect) 
replaces it. One feature that SQLTemplate supported is multiple sets of 
PreparedStatement parameters ("batches"), that we can potentially port to 
SQLExec.

4. Replace QueryResponse with QueryResult. Same thing, better API. Keeping them 
both is redundant.

5. "statementFetchSize" should be fully integrated. Currently it has no effect 
on MySQL, without somehow manually setting a few extra Statement parameters [1] 
:

conn.createStatement(ResultSet.TYPE_FORWARD_ONLY, 
ResultSet.CONCUR_READ_ONLY);

Cayenne should take care of it, allowing the users to process large cursors [2].

6. "timeout(long,TimeUnit)" - should result in setting Statement timeout. Need 
to test how well it works on different DBs.

Andrus


[1] 
https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-implementation-notes.html
 

[2] https://github.com/nhl/link-move/issues/142

Re: Records and result auto-mapping

[Andrus Adamchik]

Nice! Yeah, I remember we discussed such an explicit mapping, which addresses 
the POJO mapping case as is. 

So now I am thinking whether we can make it even more transparent - automap 
property names to column names and JDBC types to Java types. So users won't 
need "Constructor(Object[])", and generally would not concern themselves with 
the ordering of properties in the array (mapping by name instead of position).

Andrus


> On Jul 15, 2022, at 5:37 AM, Nikita Timofeev  
> wrote:
> 
> We already have map(Function) method available in both ColumnSelect
> and SQLSelect that allows to map result from Object[] to anything via
> provided function.
> Here is an example from tests [1]:
> 
> List result = SQLSelect.columnQuery("SELECT * FROM
> ARTIST_CT",
>  Integer.class, String.class, LocalDateTime.class)
>  .map(ArtistDataWrapper::new)
>  .select(context);
> 
> And I experimented with simple PojoMapper that does almost exactly
> what you are suggesting. Not sure if it's available though.
> 
> [1] 
> https://github.com/apache/cayenne/blob/336f0e5297fe6ccdc3b1904ab4f6ee2c6d1ab9dc/cayenne-server/src/test/java/org/apache/cayenne/query/SQLSelectIT.java#L273
> 
> On Thu, Jul 14, 2022 at 10:52 PM Andrus Adamchik  wrote:
>> 
>> Java 17 "records" create some interesting possibilities as quick DTOs. 
>> Mapping complex SQL is still rather painful in Cayenne. You'd get an 
>> Object[] as a result and/or need complex scripting within SQL. I think 
>> records and some API tweaks can help:
>> 
>> 1. SQL result mapping.
>> 
>> record MyRecord(String lastName, String firstName) {} // non-persistent, not 
>> in DataMap
>> 
>> SQLSelect.query("select * from x")
>> 
>>  // new API analogous to "#result" directive but simpler to use
>>  // also we can implement some implicit name conversions ("AB_C" -> "abC")
>>  .resultColumn(0, "firstName")
>>  .resultColumn("LAST_NAME", "lastName")
>> 
>>  // new API - auto-mapping the result to a POJO (record in this case)
>>  .selectAs(MyRecord.class, context);
>> 
>> 
>> 2. Entity result mapping (e.g. a replacement of column and data row queries).
>> 
>> class MyEntity extends _MyEntity {} // Persistent
>> record MyEntityDTO(..) {}  // non-persistent, not in DataMap
>> 
>> List result = ObjectSelect(MyEntity.class)
>>  .where(MyEntity.NAME.like("Joe"))
>>  .prefetch(MyEntity.ANOTHER.joint())
>> 
>>  // new API - auto-mapping the result to a POJO (record in this case)
>>  .selectAs(MyEntityDTO.class, context);
>> 
>> It will be faster than fetching MyEntity (without ObjectContext 
>> registration, uniquing, merging), and will be a good replacement of column 
>> queries API, requiring no explicit column declarations, and producing a 
>> specific type instead of Object[]. Prefetches can be auto-mapped to record 
>> hierarchies.
>> 
>> Both examples would work with either records or regular POJOs, it is just 
>> that record definitions are so easy to create on the spot, that they can be 
>> used in a multitude of very narrow contexts.
>> 
>> Andrus
>> 
> 
> 
> -- 
> Best regards,
> Nikita Timofeev

Re: Cayenne 5.0 - getting rid of legacy

[Andrus Adamchik]

With the latest DB Sync I use Modeler much more than I did before :) 


> On Jul 14, 2022, at 5:51 PM, Michael Gentry  wrote:
> 
> Any interfaces. Wasn't even thinking about Cayenne-specific ones at that
> point. Maybe I used the modeler more than you do. :-)
> 
> 
> On Thu, Jul 14, 2022 at 4:15 PM Andrus Adamchik  wrote:
> 
>> 
>> 
>>> On Jul 14, 2022, at 4:04 PM, Michael Gentry  wrote:
>>> 
>>> On Thu, Jul 14, 2022 at 3:47 PM Andrus Adamchik 
>> wrote:
>>> 
>>>> I see. I suppose if we decide to go deep into class generation beyond
>>>> property handling, we will have other options, like generating interface
>>>> methods, etc.
>>>> 
>>> 
>>> For a modeler re-write, I was planning on having a section where you
>> could
>>> specify interfaces for a class (and update the XML to support it)...
>> 
>> Do you mean Cayenne-specific interfaces (like Validating) or arbitrary
>> interfaces? If it is the latter, we'd be competing with the IDE, something
>> we really don't want to do.
>> 
>> Andrus

Re: Cayenne 5.0 - getting rid of legacy

[Andrus Adamchik]

> On Jul 14, 2022, at 4:04 PM, Michael Gentry  wrote:
> 
> On Thu, Jul 14, 2022 at 3:47 PM Andrus Adamchik  wrote:
> 
>> I see. I suppose if we decide to go deep into class generation beyond
>> property handling, we will have other options, like generating interface
>> methods, etc.
>> 
> 
> For a modeler re-write, I was planning on having a section where you could
> specify interfaces for a class (and update the XML to support it)...

Do you mean Cayenne-specific interfaces (like Validating) or arbitrary 
interfaces? If it is the latter, we'd be competing with the IDE, something we 
really don't want to do.

Andrus

Re: Cayenne 5.0 - getting rid of legacy

[Andrus Adamchik]

So even in your case you'd bootstrap ServerRuntime in a different way than that 
legacy approach. And now there are two servlet options - javax and jakarta, 
both requiring separate modules. So properly maintaining it in Cayenne is not 
that trivial anymore. Maybe we move it to Cayenne examples instead - 
https://github.com/apache/cayenne-examples 
<https://github.com/apache/cayenne-examples> 

Andrus


> On Jul 14, 2022, at 2:40 PM, John Huss  wrote:
> 
> I'm good with all of that. Except we do use cayenne-web (stateless). It's
> not a lot of code so we could pull it in and keep our own copy, but I
> wonder how many people are using it. We're not defining the serverRuntime
> in web.xml (which would be a bit limiting and clunky), but otherwise I like
> the convenience it provides for using cayenne in a servlet environment.
> 
> On Thu, Jul 14, 2022 at 11:29 AM Andrus Adamchik 
> wrote:
> 
>> I agree. Though I suggest to keep it in the current untested mode for
>> another cycle. Let's officially deprecate it in 5.0 and see if we get any
>> feedback.
>> 
>> Andrus
>> 
>>> On Jul 7, 2022, at 2:46 PM, Nikita Timofeev 
>> wrote:
>>> 
>>> Code itself is small and easy to maintain, as it doesn't do much. We
>>> just don't have a proper test suit for it and I'm sure not all Cayenne
>>> modules are compatible with OSGI, at least we have some non-unque
>>> packages (partially this would be resolved once we drop bunch of
>>> deprecated modules),
>>> If we keep it as is, is not much of a problem, I just don't like those
>>> parts with unknown state.
>>> 
>>> On Thu, Jul 7, 2022 at 7:02 PM Andrus Adamchik 
>> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Jul 5, 2022, at 2:00 PM, Nikita Timofeev 
>> wrote:
>>>>> 
>>>>> Id like to add OSGi support to that removal list as well.
>>>> 
>>>> OSGi support was developed in response to a user request (should be
>> somewhere in the mailing list archives). I have no idea if anyone is still
>> using it, and I am generally unclear on the state of OSGi these days. So
>> how hard is it to keep it around?
>>>> 
>>>> Andrus
>>> 
>>> 
>>> 
>>> --
>>> Best regards,
>>> Nikita Timofeev
>> 
>> 

Records and result auto-mapping

[Andrus Adamchik]

Java 17 "records" create some interesting possibilities as quick DTOs. Mapping 
complex SQL is still rather painful in Cayenne. You'd get an Object[] as a 
result and/or need complex scripting within SQL. I think records and some API 
tweaks can help:

1. SQL result mapping.

record MyRecord(String lastName, String firstName) {} // non-persistent, not in 
DataMap

SQLSelect.query("select * from x")

  // new API analogous to "#result" directive but simpler to use
  // also we can implement some implicit name conversions ("AB_C" -> "abC")
  .resultColumn(0, "firstName") 
  .resultColumn("LAST_NAME", "lastName") 

  // new API - auto-mapping the result to a POJO (record in this case)
  .selectAs(MyRecord.class, context);


2. Entity result mapping (e.g. a replacement of column and data row queries).

class MyEntity extends _MyEntity {} // Persistent
record MyEntityDTO(..) {}  // non-persistent, not in DataMap

List result = ObjectSelect(MyEntity.class)
  .where(MyEntity.NAME.like("Joe"))
  .prefetch(MyEntity.ANOTHER.joint())

  // new API - auto-mapping the result to a POJO (record in this case)
  .selectAs(MyEntityDTO.class, context);

It will be faster than fetching MyEntity (without ObjectContext registration, 
uniquing, merging), and will be a good replacement of column queries API, 
requiring no explicit column declarations, and producing a specific type 
instead of Object[]. Prefetches can be auto-mapped to record hierarchies.

Both examples would work with either records or regular POJOs, it is just that 
record definitions are so easy to create on the spot, that they can be used in 
a multitude of very narrow contexts.

Andrus

Re: Cayenne 5.0 - getting rid of legacy

[Andrus Adamchik]

> I've rather hipothetical case in my head where one could use callbacks
> in the model to generate some project-specific code for the callback
> instead of just empty methods (like audit or validation logic).
> Maybe that's not an optimal solution for that (especially as we have
> listeners for instance). Just thought I should mention that.

I see. I suppose if we decide to go deep into class generation beyond property 
handling, we will have other options, like generating interface methods, etc.

> As for transition, we should experiment to see if we could generate
> annotations, as manual coding could be a real demotivation for the
> upgrade.
 
Changing the existing subclass would require messing with custom code. But 
maybe we don't need to do it. Instead we can both guide and force the user to 
do the right thing. Say I have an existing class:

class _Book {
   abstract void onPostAdd() {}
}

class Book extends Book {
   @Override
   void onPostAdd() {}
}

When the user upgrades the project, in the Modeler we would mention the classes 
affected and specific annotations required. After class generation under 5.0, 
the abstract super method will go away, and the uuser will get a compiler error 
in the subclass pointing to the exact place that needs an upgrade. Shouldn't be 
too bad I think.

Andrus






> On Jul 5, 2022, at 12:37 PM, Nikita Timofeev  
> wrote:
> 
> I've rather hipothetical case in my head where one could use callbacks
> in the model to generate some project-specific code for the callback
> instead of just empty methods (like audit or validation logic).
> Maybe that's not an optimal solution for that (especially as we have
> listeners for instance). Just thought I should mention that.
> 
> As for transition, we should experiment to see if we could generate
> annotations, as manual coding could be a real demotivation for the
> upgrade.
> 
> On Tue, Jul 5, 2022 at 6:27 PM Andrus Adamchik  wrote:
>> 
>> Cool, let's stay on 11. I suppose it is integration frameworks like Bootique 
>> that should take the lead on JDK upgrades. And universal libraries like 
>> Cayenne should stay more conservative.
>> 
>> 
>> I disagree about callbacks though. Callbacks are code (custom logic), and 
>> code is better handled in the IDE. Back in the day when we required mapping 
>> of "listeners" in the Modeler (listeners are callback counterparts that are 
>> not themselves persistent objects), it created extreme tension in the dev 
>> workflow. Callbacks are not as bad as listeners, but still bad.
>> 
>>> To me it is easier to see them in the modeler. You don't have to go find 
>>> the documentation to learn what is
>>> available. Annotations are great, but only if you know them already. Even
>>> by-convention is good IMO. Can have an empty onPostLoad() in the superclass
>>> and the IDE can help you remember the event/method when you need to
>>> override it.
>> 
>> I would agree if we had a superclass that includes *all* callbacks as empty 
>> methods with fixed names (which we don't for performance reasons). What we 
>> have instead is user-defined (in the Modeler) callback methods with custom 
>> names. Two problems with it:
>> 
>> 1. Logical: Most callbacks are meaningless in the context of the mapping. So 
>> arguably this is the wrong place for them. (The only case I know of where a 
>> callback belongs in the model is setting defaults in PostAdd. Which points 
>> to the need to simply add "default" value to ObjAttribute and not use 
>> callbacks for this.
>> 2. Practical: When I am adding a callback, I am usually in the midst of 
>> coding some application function, and don't even have the Modeler open. I 
>> have to (1) open the modeler, (2) declare a callback method, (3) regenerate 
>> Java classes and (4) override the method in subclass and implement it. Looks 
>> wasteful, as I can simply do #4 with annotations.
>> 
>>>> Another idea I got is that having these callback in the model could give 
>>>> more synergy with the code generation, especially after we push it's 
>>>> usability a bit in the modeler (I've got some prototypes already for this).
>> 
>> Could you elaborate please? In my experience, callback methods that come 
>> from the Modeler look "orphaned" and give IDE warnings, as they are not 
>> explicitly invoked by any code, and provide no hint as to their specific 
>> role in the lifecycle.
>> 
>>>> - dropping callbacks will require substantial effort for the end users
>>>> to update their code, so at least we'll need to think how to automate
>>>> this process.

Re: Cayenne 5.0 - getting rid of legacy

[Andrus Adamchik]

I agree. Though I suggest to keep it in the current untested mode for another 
cycle. Let's officially deprecate it in 5.0 and see if we get any feedback.

Andrus

> On Jul 7, 2022, at 2:46 PM, Nikita Timofeev  wrote:
> 
> Code itself is small and easy to maintain, as it doesn't do much. We
> just don't have a proper test suit for it and I'm sure not all Cayenne
> modules are compatible with OSGI, at least we have some non-unque
> packages (partially this would be resolved once we drop bunch of
> deprecated modules),
> If we keep it as is, is not much of a problem, I just don't like those
> parts with unknown state.
> 
> On Thu, Jul 7, 2022 at 7:02 PM Andrus Adamchik  wrote:
>> 
>> 
>> 
>>> On Jul 5, 2022, at 2:00 PM, Nikita Timofeev  
>>> wrote:
>>> 
>>> Id like to add OSGi support to that removal list as well.
>> 
>> OSGi support was developed in response to a user request (should be 
>> somewhere in the mailing list archives). I have no idea if anyone is still 
>> using it, and I am generally unclear on the state of OSGi these days. So how 
>> hard is it to keep it around?
>> 
>> Andrus
> 
> 
> 
> -- 
> Best regards,
> Nikita Timofeev

Re: Cayenne 5.0 - getting rid of legacy

[Andrus Adamchik]

> On Jul 5, 2022, at 2:00 PM, Nikita Timofeev  wrote:
> 
> Id like to add OSGi support to that removal list as well.

OSGi support was developed in response to a user request (should be somewhere 
in the mailing list archives). I have no idea if anyone is still using it, and 
I am generally unclear on the state of OSGi these days. So how hard is it to 
keep it around?

Andrus

Re: Cayenne 5.0 - getting rid of legacy

[Andrus Adamchik]

> This sounds more interesting to me.

Seems like such a simple OO approach would be cleaner than either manual 
mapping + class generation or annotations (that don't tell you which arguments 
the method can take and what return values are expected). 

> If you group them all into a single LifecycleCallbacks
> interface, though, then yeah, you'd want default methods and call them
> blindly (they would either do nothing -- the default -- or run the object's
> lifecycle code).

That was the idea. The assumption being that learning a single interface can be 
easier that 7 different interfaces. Need to test the practicality of it though. 
Maybe one interface per callback is a less "weird" way of doing it.

> One possible advantage of annotations is you could include
> several @PostAdd-annotated methods, but then you'd potentially have calling
> order issues.

Yep, this is the advantage that quickly becomes a disadvantage. 

>  When we did post-adds, we'd put all the changes in one method
> or have that one method call smaller ones in-order.

That's exactly how I would do it, no need for extra abstractions.

Andrus



> On Jul 5, 2022, at 6:55 PM, Michael Gentry  wrote:
> 
> On Tue, Jul 5, 2022 at 11:46 AM Andrus Adamchik  wrote:
> 
>> Now that "default" implementations of interface methods are possible...
>> 
> 
> This sounds more interesting to me. I'm assuming you mean a separate
> interface per callback? Something like PostAddLifecyleCallback? You
> wouldn't need a default method implementation in that case. If you
> implement the interface, you should implement the method. It'll also be
> easier for Cayenne to test if the object implements a given lifecycle
> interface. If you group them all into a single LifecycleCallbacks
> interface, though, then yeah, you'd want default methods and call them
> blindly (they would either do nothing -- the default -- or run the object's
> lifecycle code).
> 
> One possible advantage of annotations is you could include
> several @PostAdd-annotated methods, but then you'd potentially have calling
> order issues. When we did post-adds, we'd put all the changes in one method
> or have that one method call smaller ones in-order. I think I'd prefer the
> certainty of a single method (via interface) than random annotation
> orderings. Of course, can always throw a runtime error if more than one
> method has the same annotation, but I think not having that error at
> runtime is a better approach.

Re: Cayenne 5.0 - getting rid of legacy

[Andrus Adamchik]

Now that we are talking about callbacks, there's another confusing part about 
lifecycle of Persistent. It is not clear to a regular user (or to an advanced 
user for that matter :)), what is the relationship between callbacks and the 
validation API (implemented via the "Validating" interface).

In my TODO that I was going to discuss here soon I have a big section on 
improving validation. Maybe we should review it together with callbacks, 
providing a single consistent lifecycle model. And maybe instead of either 
Modeler or annotations, we can define the entire lifecycle in terms of 
interfaces?

Now that "default" implementations of interface methods are possible, we don't 
need annotations to achieve good performance (if we can use reflection to tell 
who implements a given method - the interface or the class. I think we can 樂)

Andrus

P.S. all of these ideas are compatible with removing callbacks from the Modeler 
:) 


> On Jul 5, 2022, at 5:27 PM, Andrus Adamchik  wrote:
> 
> Cool, let's stay on 11. I suppose it is integration frameworks like Bootique 
> that should take the lead on JDK upgrades. And universal libraries like 
> Cayenne should stay more conservative.
> 
> 
> I disagree about callbacks though. Callbacks are code (custom logic), and 
> code is better handled in the IDE. Back in the day when we required mapping 
> of "listeners" in the Modeler (listeners are callback counterparts that are 
> not themselves persistent objects), it created extreme tension in the dev 
> workflow. Callbacks are not as bad as listeners, but still bad. 
> 
>> To me it is easier to see them in the modeler. You don't have to go find the 
>> documentation to learn what is
>> available. Annotations are great, but only if you know them already. Even
>> by-convention is good IMO. Can have an empty onPostLoad() in the superclass
>> and the IDE can help you remember the event/method when you need to
>> override it.
> 
> I would agree if we had a superclass that includes *all* callbacks as empty 
> methods with fixed names (which we don't for performance reasons). What we 
> have instead is user-defined (in the Modeler) callback methods with custom 
> names. Two problems with it:
> 
> 1. Logical: Most callbacks are meaningless in the context of the mapping. So 
> arguably this is the wrong place for them. (The only case I know of where a 
> callback belongs in the model is setting defaults in PostAdd. Which points to 
> the need to simply add "default" value to ObjAttribute and not use callbacks 
> for this.
> 2. Practical: When I am adding a callback, I am usually in the midst of 
> coding some application function, and don't even have the Modeler open. I 
> have to (1) open the modeler, (2) declare a callback method, (3) regenerate 
> Java classes and (4) override the method in subclass and implement it. Looks 
> wasteful, as I can simply do #4 with annotations.
> 
>>> Another idea I got is that having these callback in the model could give 
>>> more synergy with the code generation, especially after we push it's 
>>> usability a bit in the modeler (I've got some prototypes already for this).
> 
> Could you elaborate please? In my experience, callback methods that come from 
> the Modeler look "orphaned" and give IDE warnings, as they are not explicitly 
> invoked by any code, and provide no hint as to their specific role in the 
> lifecycle. 
> 
>>> - dropping callbacks will require substantial effort for the end users
>>> to update their code, so at least we'll need to think how to automate
>>> this process. 
> 
> I hope it won't be the case. They will just need to revisit the existing 
> methods and annotate them. We can generate a full list during XML upgrade 
> step.
> 
> Andrus
> 
>> On Jul 5, 2022, at 3:20 PM, Michael Gentry  wrote:
>> 
>> I agree with Nikita's JDK 17 comment. I just got people to switch to JDK
>> 11...
>> 
>> Also kind of his callbacks comment. To me it is easier to see them in the
>> modeler. You don't have to go find the documentation to learn what is
>> available. Annotations are great, but only if you know them already. Even
>> by-convention is good IMO. Can have an empty onPostLoad() in the superclass
>> and the IDE can help you remember the event/method when you need to
>> override it.
>> 
>> Thanks,
>> 
>> mrg
>> 
>> 
>> On Tue, Jul 5, 2022 at 8:01 AM Nikita Timofeev 
>> wrote:
>> 
>>> Hi all,
>>> 
>>> I'm really looking forward to drop old modules as I don't really sure
>>> if they are still really usable after all major changes to the core we
>>> had

Re: Cayenne 5.0 - getting rid of legacy

[Andrus Adamchik]

Cool, let's stay on 11. I suppose it is integration frameworks like Bootique 
that should take the lead on JDK upgrades. And universal libraries like Cayenne 
should stay more conservative.


I disagree about callbacks though. Callbacks are code (custom logic), and code 
is better handled in the IDE. Back in the day when we required mapping of 
"listeners" in the Modeler (listeners are callback counterparts that are not 
themselves persistent objects), it created extreme tension in the dev workflow. 
Callbacks are not as bad as listeners, but still bad. 

> To me it is easier to see them in the modeler. You don't have to go find the 
> documentation to learn what is
> available. Annotations are great, but only if you know them already. Even
> by-convention is good IMO. Can have an empty onPostLoad() in the superclass
> and the IDE can help you remember the event/method when you need to
> override it.

I would agree if we had a superclass that includes *all* callbacks as empty 
methods with fixed names (which we don't for performance reasons). What we have 
instead is user-defined (in the Modeler) callback methods with custom names. 
Two problems with it:

1. Logical: Most callbacks are meaningless in the context of the mapping. So 
arguably this is the wrong place for them. (The only case I know of where a 
callback belongs in the model is setting defaults in PostAdd. Which points to 
the need to simply add "default" value to ObjAttribute and not use callbacks 
for this.
2. Practical: When I am adding a callback, I am usually in the midst of coding 
some application function, and don't even have the Modeler open. I have to (1) 
open the modeler, (2) declare a callback method, (3) regenerate Java classes 
and (4) override the method in subclass and implement it. Looks wasteful, as I 
can simply do #4 with annotations.

>> Another idea I got is that having these callback in the model could give 
>> more synergy with the code generation, especially after we push it's 
>> usability a bit in the modeler (I've got some prototypes already for this).

Could you elaborate please? In my experience, callback methods that come from 
the Modeler look "orphaned" and give IDE warnings, as they are not explicitly 
invoked by any code, and provide no hint as to their specific role in the 
lifecycle. 

>> - dropping callbacks will require substantial effort for the end users
>> to update their code, so at least we'll need to think how to automate
>> this process. 

I hope it won't be the case. They will just need to revisit the existing 
methods and annotate them. We can generate a full list during XML upgrade step.

Andrus

> On Jul 5, 2022, at 3:20 PM, Michael Gentry  wrote:
> 
> I agree with Nikita's JDK 17 comment. I just got people to switch to JDK
> 11...
> 
> Also kind of his callbacks comment. To me it is easier to see them in the
> modeler. You don't have to go find the documentation to learn what is
> available. Annotations are great, but only if you know them already. Even
> by-convention is good IMO. Can have an empty onPostLoad() in the superclass
> and the IDE can help you remember the event/method when you need to
> override it.
> 
> Thanks,
> 
> mrg
> 
> 
> On Tue, Jul 5, 2022 at 8:01 AM Nikita Timofeev 
> wrote:
> 
>> Hi all,
>> 
>> I'm really looking forward to drop old modules as I don't really sure
>> if they are still really usable after all major changes to the core we
>> had for the past years. So this is more than welcomed changed for me.
>> Id like to add OSGi support to that removal list as well.
>> 
>> I have some concerns however regarding points 0 and 7.
>> 
>> - requiring JDK 17 version may limit adoption, as I believe there are
>> many projects that can't update to Java 17 yet and there are no
>> immediate benefits that I could see for Cayenne (though I like the
>> idea of using fresh Java).
>> But upgrading to 11 could be good as it will allow to drop some ugly
>> hacks at least in the Modeler.
>> 
>> - dropping callbacks will require substantial effort for the end users
>> to update their code, so at least we'll need to think how to automate
>> this process. Another idea I got is that having these callback in the
>> model could give more synergy with the code generation, especially
>> after we push it's usability a bit in the modeler (I've got some
>> prototypes already for this).
>> 
>> On Sun, Jul 3, 2022 at 2:17 PM Andrus Adamchik 
>> wrote:
>>> 
>>> 8. Modeler DataNode configuration should be drastically simplified:
>>> 
>>> * Password encoder should be externalized. If you need a custom password
>> storage mechanism, use your own DataSource, such a

Re: Cayenne 5.0 - getting rid of legacy

[Andrus Adamchik]

8. Modeler DataNode configuration should be drastically simplified:

* Password encoder should be externalized. If you need a custom password 
storage mechanism, use your own DataSource, such as Hikari, and write your own 
code to obtain the password outside Cayenne. E.g. we don't support (nor should 
we support it) the most common way of modern password resolving - cloud secrets 
managers.
* Adapter seclection can probably be moved to the main (and only) tab
* Get rid of JNDI DataSource (let the users provide it as a custom factory)
* Only leave the selection of "Provided by Cayenne" and "Custom DataSource"

This is in line with our long-term direction towards CayenneModeler being an OR 
mapping tool, maximally free of deployment details.

Andrus

> On Jul 1, 2022, at 6:11 PM, Andrus Adamchik  wrote:
> 
> Hi folks,
> 
> So with 4.2 being almost GA, it is about time to start discussing the next 
> major release. I think it should be 5.0 (not 4.3), and we would modernize 
> things across the board. Let me start with a list of things we can clean up, 
> and I'll follow up with new feature ideas in a separate thread. So...
> 
> 0. Switch to Java 17. About time...
> 
> 1. [Done by Nikita] Remove OpenBaseAdapter
> 
> 2. [Done by Nikita] Remove cayenne-dbcp2, cayenne-joda
> 
> 3. Remove ROP (cayenne-client, cayenne-client-jetty, cayenne-protostuff, 
> cayenne-rop-server, ROP modeler pieces, docs). It is untenable to support it 
> anymore, and is a constant source of CVE's. Most importantly, from what I can 
> tell, there are no users left for this particular technology. Removing it 
> would allow us to collapse ObjectContext inheritance hierarchy among other 
> things.
> 
> 4. Remove object clustering transports (cayenne-jgroups, cayenne-jms, 
> cayenne-xmpp). I don't think anyone uses them. Also these transport protocols 
> are not particularly popular these days. Whoever needs them, can easily 
> maintain their own fork. 
> 
> 5. Remove cayenne-web. It provides a very specific recipe for integration 
> with servlets via ThreadLocals. Kinda old-school. I'd rather see a SpringBoot 
> example as a separate project somewhere. (And of course we already have 
> Bootique examples available).
> 
> 6. Remove deprecated SelectQuery. ObjectSelect is a full replacement. There 
> are more query improvements that I have in mind, but this one is a no brainer.
> 
> 7. Remove entity callbacks from the Modeler and XML. Only annotated callbacks 
> will be supported.
> 
> Comments?
> 
> Andrus

Cayenne 5.0 - getting rid of legacy

[Andrus Adamchik]

Hi folks,

So with 4.2 being almost GA, it is about time to start discussing the next 
major release. I think it should be 5.0 (not 4.3), and we would modernize 
things across the board. Let me start with a list of things we can clean up, 
and I'll follow up with new feature ideas in a separate thread. So...

0. Switch to Java 17. About time...

1. [Done by Nikita] Remove OpenBaseAdapter

2. [Done by Nikita] Remove cayenne-dbcp2, cayenne-joda

3. Remove ROP (cayenne-client, cayenne-client-jetty, cayenne-protostuff, 
cayenne-rop-server, ROP modeler pieces, docs). It is untenable to support it 
anymore, and is a constant source of CVE's. Most importantly, from what I can 
tell, there are no users left for this particular technology. Removing it would 
allow us to collapse ObjectContext inheritance hierarchy among other things.

4. Remove object clustering transports (cayenne-jgroups, cayenne-jms, 
cayenne-xmpp). I don't think anyone uses them. Also these transport protocols 
are not particularly popular these days. Whoever needs them, can easily 
maintain their own fork. 

5. Remove cayenne-web. It provides a very specific recipe for integration with 
servlets via ThreadLocals. Kinda old-school. I'd rather see a SpringBoot 
example as a separate project somewhere. (And of course we already have 
Bootique examples available).

6. Remove deprecated SelectQuery. ObjectSelect is a full replacement. There are 
more query improvements that I have in mind, but this one is a no brainer.

7. Remove entity callbacks from the Modeler and XML. Only annotated callbacks 
will be supported.

Comments?

Andrus

[ANN] Release 4.2.RC1

[Andrus Adamchik]

Glad to announce Cayenne 4.2 release candidate. It fixes a few remaining JDK 17 
compatibility issues (Gradle, protostuff/ROP). Also a number of bug fixes. Very 
good chance the next 4.2 release will be "GA".

Full list of bug fixes:

CAY-2711 JDK 17 compatibility
CAY-2728 Add ExtendedType to generate user-friendly exceptions for internally 
used values
CAY-2630 Prefetched relationships not preserving pending changes
CAY-2697 Read-only cgen template creates mutator methods for to-many 
relationships
CAY-2724 Duplicating relationship after editing its name
CAY-2727 Modeler: cgen destDir Unix platform path separator
CAY-2729 Unable to use custom templates from a folder at upper level then 
datamap
CAY-2730 Duplicating lines in a cgen config saved to datamap.xml
CAY-2731 Exception when setting a CLOB on H2 v2.0.202
CAY-2733 Modeler can’t use custom templates set in a datamap
CAY-2734 Improve support for the DECIMAL type
CAY-2736 Can’t use function names as a path in a string-based expression

Cheers,
Andrus

Re: [VOTE] Apache Cayenne 4.2.RC1 release

[Andrus Adamchik]

Congrats! Will be upgrading Agrest and Bootique shortly.

Cheers,
Andrus

> On Jun 10, 2022, at 1:20 PM, Nikita Timofeev  
> wrote:
> 
> With my +1 the result is following:
> 
> Michael Gentry (PMC): +1
> Andrus Adamchik (PMC): +1
> John Huss (PMC): +1
> Nikita Timofeev (PMC): +1
> 
> I will finish this release today.
> Thanks everyone!
> 
> On Mon, Jun 6, 2022 at 6:58 PM John Huss  wrote:
>> 
>> +1
>> All my checks passed on the mac with Java 17.
>> 
>> On Mon, Jun 6, 2022 at 10:48 AM Andrus Adamchik  wrote:
>> 
>>> All my checks pass. +1
>>> 
>>>> On Jun 3, 2022, at 2:23 PM, Nikita Timofeev 
>>> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> Here is a 4.2.RC1 release as promised.
>>>> 
>>>> Release notes:
>>> https://github.com/apache/cayenne/blob/4.2.RC1/RELEASE-NOTES.txt
>>>> Maven repo:
>>> https://repository.apache.org/content/repositories/orgapachecayenne-1049/
>>>> Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.2.RC1/
>>>> 
>>>> Please evaluate and cast your votes.
>>>> 
>>>> --
>>>> Best regards,
>>>> Nikita Timofeev
>>> 
>>> 
> 
> 
> 
> -- 
> Best regards,
> Nikita Timofeev

Re: [VOTE] Apache Cayenne 4.2.RC1 release

[Andrus Adamchik]

All my checks pass. +1

> On Jun 3, 2022, at 2:23 PM, Nikita Timofeev  wrote:
> 
> Hi all,
> 
> Here is a 4.2.RC1 release as promised.
> 
> Release notes: 
> https://github.com/apache/cayenne/blob/4.2.RC1/RELEASE-NOTES.txt
> Maven repo: 
> https://repository.apache.org/content/repositories/orgapachecayenne-1049/
> Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.2.RC1/
> 
> Please evaluate and cast your votes.
> 
> -- 
> Best regards,
> Nikita Timofeev

Re: Release Candidate of the 4.2

[Andrus Adamchik]

Good catch! Def something we'd like to change in 4.3/5.0

> On May 31, 2022, at 11:14 AM, Hugi Thordarson  wrote:
> 
> Hi Nikita,
> 
> That's cool! I've unfortunately had little opportunity to check out 4.2 
> lately (still stuck with a mutilated 4.1 for…reasons) but incidentally 
> started looking at a migration last weekend.
> 
> I absolutely love the typed properties—one quick observation is that there's 
> a "DateProperty" that represents both date and a time. It feels like it would 
> more appropriately called "DateTimeProperty", leaving room for a later actual 
> "DateProperty" (date only) and even a "TimeProperty" (time only), to properly 
> represent the types and align with the corresponding java.time types/class 
> names. The time functions of DateProperty won't apply do a DATE field.
> 
> API changes like this are probably too late at this beta stage (shame on me 
> for being so late to the 4.2 party) but I still thought I'd mention it since 
> it's an API that can somewhat reverberate into the future.
> 
> Cheers,
> - hugi
> 
> 
> 
>> On 31 May 2022, at 08:31, Nikita Timofeev  wrote:
>> 
>> Hi all,
>> 
>> Looks like it's a good time for the 4.2.RC1 version. No serious
>> problems were found in B1 and not much happening with 4.2 right now.
>> So, if there's nothing I'm missing I'll start the release process this week.
>> 
>> --
>> Best regards,
>> Nikita Timofeev
> 

Re: Next releases

[Andrus Adamchik]

+1

> On Feb 22, 2022, at 4:32 AM, Aristedes Maniatis  
> wrote:
> 
> I'm thinking:
> 
> 
> *  3.1.3 be marked on the website "EOL".
> 
> * 4.0.2 be marked as "Security fixes only"
> 
> * 4.1.1 be marked as "Security and bug fixes"
> 
> * 4.2 start the RC process and get it released in a month or so.
> 
> * main branch: remove ROP
> 
> 
> 
> https://www.php.net/supported-versions.php
> 
> 
> 
> Thoughts?
> 
> 
> Ari
> 

Re: Buildbot

[Andrus Adamchik]

Revisiting our October discussion, it appears that even in its current 
curtailed form Travis is better than Buildbot. It supports containers, we have 
cross-DB builds working there, and we publish .jar snapshots from it:

https://repository.apache.org/content/repositories/snapshots/org/apache/cayenne/cayenne-di/4.2.B2-SNAPSHOT/
 
<https://repository.apache.org/content/repositories/snapshots/org/apache/cayenne/cayenne-di/4.2.B2-SNAPSHOT/>

Publishing Modeler assemblies is the only thing that's missing. 

Buildbot still seems redundant, but can it solve the platform builds issue?

Andrus

> On Jan 25, 2022, at 2:58 AM, Aristedes Maniatis  
> wrote:
> 
> github actions aren't an option for us due to the limits in the quota and 
> travis also restricted their offering to open source. Don't we need somewhere 
> we can test against lots of database options?
> 
> 
> Also, we had this from ages ago: https://nightlies.apache.org/cayenne/   Is 
> fixing this up to put nightly builds back a useful thing?
> 
> 
> 
> Ari
> 
> 
> 
> On 24/1/2022 4:40pm, Andrus Adamchik wrote:
>> I suggest we just take it down. We have CI working elsewhere, so why spend 
>> the effort.
>> 
>> Andrus
>> 
>>> On Jan 24, 2022, at 4:23 AM, Aristedes Maniatis  
>>> wrote:
>>> 
>>> https://ci2.apache.org/#/builders/95/builds/2/steps/2/logs/stdio
>>> 
>>> 
>>> Infra have gotten buildbot working again for us. However the build is 
>>> failing against
>>> 
>>> testConstructorWithProperties(org.apache.cayenne.access.DataRowStoreTest)
>>> 
>>> 
>>> 
>>> Ari

Re: Buildbot

[Andrus Adamchik]

I suggest we just take it down. We have CI working elsewhere, so why spend the 
effort.

Andrus

> On Jan 24, 2022, at 4:23 AM, Aristedes Maniatis  
> wrote:
> 
> https://ci2.apache.org/#/builders/95/builds/2/steps/2/logs/stdio
> 
> 
> Infra have gotten buildbot working again for us. However the build is failing 
> against
> 
> testConstructorWithProperties(org.apache.cayenne.access.DataRowStoreTest)
> 
> 
> 
> Ari

"Import EOModel" support

[Andrus Adamchik]

> On Jan 1, 2022, at 3:31 PM, Michael Gentry  wrote:
> 
> "I know EOF of the olden times had an LDAP adapter..."
> 
> Wow, that brings back unpleasant memories...  Speaking of EOF (and I don't
> want to hijack this thread, so feel free to reply in a new one), how long
> is Cayenne going to support EOModels? It isn't a lot of baggage that is
> carried around, but still baggage.

This functionality is not often used, but, believe it or not, there are still 
substantial systems built on EOF out there. So this button in the Modeler 
encourages and helps them to migrate to Cayenne. 

Having said that, the current importer is somewhat limited. For instance it 
does not support multiple models. We at ObjectStyle are developing 
closed-source CLI tool for the full EOF migration. I am hoping we can open 
source it at some point. But even if we can't, we can still transfer the 
current importer to its own simple Bootique CLI. 

So I would say the current Modeler should keep the "Import EOModel" button 
around, but whatever new Modeler we develop doesn't have to, as the CLI tool 
will replace it.

Andrus

Re: groovy 4 ginq

[Andrus Adamchik]

Not so much of a connector issue, but more of a conceptual limitation. 
Relational backend is implied across the stack, from mapping (FKs, joins) to 
query translation. I know EOF of the olden times had an LDAP adapter, and there 
are JPA engines for NoSQL DBs, but all appear to be really leaky abstractions. 

If we are to dig in this direction, we will need to start with a model of 
"universal mapping".

Andrus


> On Dec 30, 2021, at 4:54 AM, Aristedes Maniatis  
> wrote:
> 
> Not that I have a need for it, but how pluggable is the JDBC connector part 
> of Cayenne? That is, could the backend be easily exchanged for json or some 
> other data source, even if only in a read-only way? Could also be an 
> interesting way to demonstrate Modeler to new users...
> 
> 
> Ari
> 
> 
> On 30/12/21 1:24am, Andrus Adamchik wrote:
>> An idea of in-memory query evaluation fits Cayenne to a degree. Though it is 
>> limited to what we already do with in-memory expression-based filtering and 
>> sorting. A more fancy data transformation (even a simple "toUpperCase" from 
>> your example) runs against the basic ORM philosophy ("toUpperCase" would be 
>> a property that does not directly correspond to a value in DB).
>> 
>> I solved it for myself by splitting use cases in two groups:
>> 
>> 1. "Data as object graph" where Cayenne is appropriate (most cases)
>> 2. "Data as data" with extra "plasticity" of changing any piece of data on 
>> the fly
>> 
>> For #2 sometimes I'd use Cayenne (e.g. column queries, SQLSelect), but most 
>> often I'd go with DFLib. The main data object in it is a DataFrame 
>> (essentially a dynamic in-memory table). DataFrame is not tied to a specific 
>> object structure, and can be dynamically transformed (columns added, 
>> removed, changed, rows filtered, joins, unions, etc.). DFLib can do what 
>> GINQ can and more, but it intentionally sacrifices a familiar OO 
>> representation to support arbitrary intermediate data states and 
>> frictionless mapping-free persistence.
>> 
>> DataFrame df = Csv.load("my.csv")
>>.selectColumns("id", "price")
>>.selectRows($decimal("price").gt(100.));
>> 
>> Jdbc.connector(dataSource)
>>.tableSaver("db_table")
>>.save(df);
>> 
>> Andrus
>> 
>> 
>>> On Dec 28, 2021, at 11:50 PM, Aristedes Maniatis  
>>> wrote:
>>> 
>>> I came across this really interesting new feature in groovy 4 today...
>>> 
>>>class Person {
>>>String name
>>>int age
>>> 
>>>Person(String name, int age) {
>>>this.name = name
>>>this.age = age
>>>}
>>>}
>>> 
>>>def persons1 = [new Person('Daniel', 35), new Person('Linda', 
>>> 21), new Person('Peter', 30)]
>>>def persons2 = [new Person('Jack', 35), new Person('Rose', 21), 
>>> new Person('Smith', 30)]
>>> 
>>> 
>>>def output = GQ {
>>>from p1 in persons1
>>>innerjoin p2 in persons2 on p1.age == p2.age
>>>select p1.name.toUpperCase(), p2.name.toUpperCase()
>>>   }
>>> 
>>>assert [['DANIEL', 'JACK'], ['LINDA', 'ROSE'], ['PETER', 
>>> 'SMITH']] == output.toList()
>>> 
>>> 
>>> So GQ invokes this sql-like query language for Java/groovy objects.
>>> 
>>> 
>>> Not suggesting it is useful for Cayenne, but interesting nevertheless.
>>> 
>>> 
>>> Ari
>>> 
>>> 
>>> 
>>> 
>>> docs:https://github.com/apache/groovy/blob/master/subprojects/groovy-ginq/src/spec/doc/ginq-userguide.adoc
>>> 
>>> examples: 
>>> https://github.com/apache/groovy/blob/master/subprojects/groovy-ginq/src/spec/test/org/apache/groovy/ginq/GinqTest.groovy
>>> 
>>> src: 
>>> https://github.com/apache/groovy/tree/master/subprojects/groovy-ginq/src/main/groovy/org/apache/groovy/ginq

Re: groovy 4 ginq

[Andrus Adamchik]

An idea of in-memory query evaluation fits Cayenne to a degree. Though it is 
limited to what we already do with in-memory expression-based filtering and 
sorting. A more fancy data transformation (even a simple "toUpperCase" from 
your example) runs against the basic ORM philosophy ("toUpperCase" would be a 
property that does not directly correspond to a value in DB).

I solved it for myself by splitting use cases in two groups:

1. "Data as object graph" where Cayenne is appropriate (most cases)
2. "Data as data" with extra "plasticity" of changing any piece of data on the 
fly

For #2 sometimes I'd use Cayenne (e.g. column queries, SQLSelect), but most 
often I'd go with DFLib. The main data object in it is a DataFrame (essentially 
a dynamic in-memory table). DataFrame is not tied to a specific object 
structure, and can be dynamically transformed (columns added, removed, changed, 
rows filtered, joins, unions, etc.). DFLib can do what GINQ can and more, but 
it intentionally sacrifices a familiar OO representation to support arbitrary 
intermediate data states and frictionless mapping-free persistence.

DataFrame df = Csv.load("my.csv")
   .selectColumns("id", "price")
   .selectRows($decimal("price").gt(100.));

Jdbc.connector(dataSource)
   .tableSaver("db_table")
   .save(df);

Andrus


> On Dec 28, 2021, at 11:50 PM, Aristedes Maniatis  
> wrote:
> 
> I came across this really interesting new feature in groovy 4 today...
> 
>class Person {
>String name
>int age
> 
>Person(String name, int age) {
>this.name = name
>this.age = age
>}
>}
> 
>def persons1 = [new Person('Daniel', 35), new Person('Linda', 21), 
> new Person('Peter', 30)]
>def persons2 = [new Person('Jack', 35), new Person('Rose', 21), 
> new Person('Smith', 30)]
> 
> 
>  def output = GQ {
>from p1 in persons1
>innerjoin p2 in persons2 on p1.age == p2.age
>select p1.name.toUpperCase(), p2.name.toUpperCase()
>   }
> 
>assert [['DANIEL', 'JACK'], ['LINDA', 'ROSE'], ['PETER', 'SMITH']] 
> == output.toList()
> 
> 
> So GQ invokes this sql-like query language for Java/groovy objects.
> 
> 
> Not suggesting it is useful for Cayenne, but interesting nevertheless.
> 
> 
> Ari
> 
> 
> 
> 
> docs:https://github.com/apache/groovy/blob/master/subprojects/groovy-ginq/src/spec/doc/ginq-userguide.adoc
> 
> examples: 
> https://github.com/apache/groovy/blob/master/subprojects/groovy-ginq/src/spec/test/org/apache/groovy/ginq/GinqTest.groovy
> 
> src: 
> https://github.com/apache/groovy/tree/master/subprojects/groovy-ginq/src/main/groovy/org/apache/groovy/ginq

Re: [VOTE] Apache Cayenne 4.1.1 release, second try

[Andrus Adamchik]

Great! Once published, I will write the announcements and add to Bootique.

Congrats everyone and happy holidays.

Andrus

> On Dec 24, 2021, at 10:50 AM, Nikita Timofeev  
> wrote:
> 
> With my +1 the result is following:
> 
> John Huss (PMC): +1
> Andrus Adamchik (PMC): +1
> Michael Gentry (PMC): +1
> Nikita Timofeev (PMC): +1
> 
> I will finish the release today.
> Thanks, everyone and happy holidays!
> 
> 
> On Thu, Dec 23, 2021 at 8:34 PM Michael Gentry  wrote:
>> 
>> Outside of the UI artifact issues I mentioned in a different e-mail, which
>> I don't believe to be a stopper, I compiled under Java 8, 11, and 14 and
>> everything passed.
>> 
>> +1
>> 
>> Thanks!
>> 
>> 
>> On Tue, Dec 21, 2021 at 3:24 AM Nikita Timofeev 
>> wrote:
>> 
>>> Hi all,
>>> 
>>> Here is another try of the 4.1.1 release. This time with Gradle
>>> upgrade and proper support for the JDK 17 in the Modeler.
>>> 
>>> Release notes:
>>> https://github.com/apache/cayenne/blob/4.1.1/RELEASE-NOTES.txt
>>> Maven repo:
>>> https://repository.apache.org/content/repositories/orgapachecayenne-1048/
>>> Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.1.1/
>>> 
>>> Please evaluate and cast your votes
>>> 
>>> --
>>> Best regards,
>>> Nikita Timofeev
>>> 
> 
> 
> 
> --
> Best regards,
> Nikita Timofeev

Re: [VOTE] Apache Cayenne 4.1.1 release, second try

[Andrus Adamchik]

All checks pass. +1


> On Dec 21, 2021, at 10:23 AM, Nikita Timofeev  
> wrote:
> 
> Hi all,
> 
> Here is another try of the 4.1.1 release. This time with Gradle
> upgrade and proper support for the JDK 17 in the Modeler.
> 
> Release notes: https://github.com/apache/cayenne/blob/4.1.1/RELEASE-NOTES.txt
> Maven repo: 
> https://repository.apache.org/content/repositories/orgapachecayenne-1048/
> Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.1.1/
> 
> Please evaluate and cast your votes
> 
> -- 
> Best regards,
> Nikita Timofeev

Re: UI toolkit for the future Modeler

[Andrus Adamchik]

d be 
> added on top of the existing ERD features? 
> https://dbeaver.com/docs/wiki/ER-Diagrams
> 
> 
> What would be involved in making Cayenne modeler an Eclipse or Intellij 
> plugin? Would that increase market awareness, especially if the IDE could be 
> made more aware of how to handle Cayenne annotations.
> 
> 
> ## Competing implementations
> 
> It is worth looking at the feature set over here:
> 
> https://tools.jboss.org/features/hibernate.html#hibernate-console
> 
> 
> I like the idea of converting a query into SQL in order to understand what it 
> is doing. But of course that needs a modeler which can talk to the Java 
> Cayenne library and might rule out a pure browser/js implementation. Rather 
> it might look like the Cayenne server library with some sort of rest API to 
> serve the front end. Cayenne as a service, if you will.
> 
> 
> 
> ## Browser/cloud modeler
> 
> A modeler which runs inside a browser reduces the barrier to entry hugely. 
> Imagine going to a demo website, uploading your database schema and being 
> able to instantly play with your schema and output a working Java project.
> 
> 
> ## Developer skills
> 
> Does anyone in the existing team have js skills?
> 
> 
> 
> Ari
> 
> 
> 
> 
> On 11/12/21 7:15pm, Andrus Adamchik wrote:
>> A datapoint to our perennial discussion of technology to use for the future 
>> CayenneModeler... With Swing being old and crusty, and JavaFX no longer 
>> supported by Oracle, perhaps we should be looking for something fresh. I 
>> just came across a new "Compose Multiplatform" desktop UI framework by 
>> JetBrains [1]. It is programmed in Kotlin and is based on Google toolkit for 
>> Android. Their GitHub examples [2] are not that visually impressive, but I 
>> would imagine it is a matter of styling. A million $ question is whether it 
>> will be around and open source in 10-15 years.
>> 
>> Anyone knows anything about it?
>> 
>> Andrus
>> 
>> [1] https://www.jetbrains.com/lp/compose-mpp/
>> [2] 
>> https://github.com/JetBrains/compose-jb/blob/master/artwork/readme/apps.png
>> 
>> 

Re: UI toolkit for the future Modeler

[Andrus Adamchik]

> Another concern I'd have is
> learning/mastering another language (Kotlin). It might be the right path,
> ultimately, but still a concern.


This is a real concern. Similar to what we previously discussed about writing 
the Modeler in JS. At least Kotlin is kinda Java though :)

> Would we be "encouraged" to use IntelliJ
> (for Kotlin support)? Haven't looked into Eclipse or even VSC support for
> Kotlin.

Kotlin is big on Android. Android Studio supports it. For non-Android use 
cases, looks like there are alternatives, but IntelliJ is still the best. As 
long as they have a non-crippled free Community Edition of IntelliJ, shouldn't 
be a big deal.

Andrus


> On Dec 11, 2021, at 4:21 PM, Michael Gentry  wrote:
> 
> I've not heard of it before. It seems that Google is kind of the upstream
> provider, but Google is known to drop things all the time, too. If that
> happened, I wonder what JetBrains would do? Another concern I'd have is
> learning/mastering another language (Kotlin). It might be the right path,
> ultimately, but still a concern. Would we be "encouraged" to use IntelliJ
> (for Kotlin support)? Haven't looked into Eclipse or even VSC support for
> Kotlin.
> 
> Looks like it already has native packaging, menu management, etc support:
> 
> https://github.com/JetBrains/compose-jb/blob/master/FEATURES.md#features-currently-available-in-compose-for-desktop
> 
> 
> Hopefully this wouldn't remain "Experimental" for long:
> 
> https://github.com/JetBrains/compose-jb/raw/master/tutorials/Getting_Started/screen3.png
> 
> 
> As for JavaFX and Oracle, I'm still confused if they are involved. The
> latest release (JavaFX 17, September 2021) still has Oracle on some of the
> docs:
> 
> https://openjfx.io/javadoc/17/javafx.fxml/javafx/fxml/doc-files/introduction_to_fxml.html
> 
> https://openjfx.io/javadoc/17/javafx.graphics/javafx/scene/doc-files/cssref.html
> 
> 
> I also really liked using Scene Builder to create the FXML visually and not
> have the UI "code" in the Java code. Compose seems more traditional and
> with the UI in the source code. Perhaps I'm just more of a visual person in
> that regard, which is another reason why I like using CM to model a DB
> instead of annotations or whatnot in code.
> 
> 
> On Sat, Dec 11, 2021 at 3:15 AM Andrus Adamchik  wrote:
> 
>> A datapoint to our perennial discussion of technology to use for the
>> future CayenneModeler... With Swing being old and crusty, and JavaFX no
>> longer supported by Oracle, perhaps we should be looking for something
>> fresh. I just came across a new "Compose Multiplatform" desktop UI
>> framework by JetBrains [1]. It is programmed in Kotlin and is based on
>> Google toolkit for Android. Their GitHub examples [2] are not that visually
>> impressive, but I would imagine it is a matter of styling. A million $
>> question is whether it will be around and open source in 10-15 years.
>> 
>> Anyone knows anything about it?
>> 
>> Andrus
>> 
>> [1] https://www.jetbrains.com/lp/compose-mpp/
>> [2]
>> https://github.com/JetBrains/compose-jb/blob/master/artwork/readme/apps.png
>> 
>> 
>> 

Re: JGroups

[Andrus Adamchik]

> setDomainStringProperty(JavaGroupsBridge.MCAST_ADDRESS_PROPERTY,
> multicastAddress, JavaGroupsBridge.MCAST_ADDRESS_DEFAULT);
> setDomainStringProperty(JavaGroupsBridge.MCAST_PORT_PROPERTY,
> multicastPort, JavaGroupsBridge.MCAST_PORT_DEFAULT);
> setDomainStringProperty(JavaGroupsBridge.JGROUPS_CONFIG_URL_PROPERTY,
> javaGroupsFile, "");
> if (StringUtils.equals(eventBridgefactory,
> JavaGroupsBridgeFactory.class.getName()))


None of these settings are in the Modeler for quite some time.

> Maybe best to duplicate the constants locally and drop the dependencies? I
> just don't like repeating things...

I'd to avoid such a heavy dependency if all we need is constants, but luckily 
not an issue anymore.

Andrus 


> On Dec 20, 2021, at 4:00 PM, Michael Gentry  wrote:
> 
> Well, I was pulling in cayenne-jgroups primarily to access constants, such
> as:
> 
> setDomainStringProperty(JavaGroupsBridge.MCAST_ADDRESS_PROPERTY,
> multicastAddress, JavaGroupsBridge.MCAST_ADDRESS_DEFAULT);
> setDomainStringProperty(JavaGroupsBridge.MCAST_PORT_PROPERTY,
> multicastPort, JavaGroupsBridge.MCAST_PORT_DEFAULT);
> setDomainStringProperty(JavaGroupsBridge.JGROUPS_CONFIG_URL_PROPERTY,
> javaGroupsFile, "");
> if (StringUtils.equals(eventBridgefactory,
> JavaGroupsBridgeFactory.class.getName()))
> ...
> 
> If I didn't add JGroupsModule as a DI module it crashed (forget the exact
> reason right now, but I can try it again later). Note: It didn't break ages
> ago when I was using 4.0.B1, but after I updated it to use 4.0.2. When
> using B1 I had access to the constants without needing to provide a JGroups
> dependency.
> 
> Maybe best to duplicate the constants locally and drop the dependencies? I
> just don't like repeating things...
> 
> mrg
> 
> 
> On Mon, Dec 20, 2021 at 1:37 AM Andrus Adamchik  wrote:
> 
>> FWIW, I was about to suggest removing "cayenne-jgroups" from Cayenne 5.0
>> as an old and unreliable piece of software we don't want to support :)
>> 
>> As far as the Modeler goes it should not depend on JGroups at all. All the
>> events in the Modeler are in-process and can be passed around within the
>> JVM.
>> 
>> Andrus
>> 
>>> On Dec 19, 2021, at 6:35 PM, Michael Gentry  wrote:
>>> 
>>> While getting the JavaFX modeler running again, I was having issues with
>>> JGroups classes/interfaces not being found/defined, so I added version
>> 5.x
>>> to the POM and it didn't work. Then 4.x and it didn't work. Then 3.x and
>> it
>>> didn't work. Then 2.x and it finally worked.
>>> 
>>> Does Cayenne only work with JGroups 2.x? *
>>> 
>>> Thanks,
>>> 
>>> mrg
>>> 
>>> * I used 2.12.3.Final here...
>> 
>> 

Re: JGroups

[Andrus Adamchik]

FWIW, I was about to suggest removing "cayenne-jgroups" from Cayenne 5.0 as an 
old and unreliable piece of software we don't want to support :) 

As far as the Modeler goes it should not depend on JGroups at all. All the 
events in the Modeler are in-process and can be passed around within the JVM.

Andrus

> On Dec 19, 2021, at 6:35 PM, Michael Gentry  wrote:
> 
> While getting the JavaFX modeler running again, I was having issues with
> JGroups classes/interfaces not being found/defined, so I added version 5.x
> to the POM and it didn't work. Then 4.x and it didn't work. Then 3.x and it
> didn't work. Then 2.x and it finally worked.
> 
> Does Cayenne only work with JGroups 2.x? *
> 
> Thanks,
> 
> mrg
> 
> * I used 2.12.3.Final here...

Re: [VOTE] Apache Cayenne 4.1.1 release

[Andrus Adamchik]

I don't fully understand the LOE or any technical issues arising from Gradle 7 
for 4.1, but as a matter of policy I think it is worth supporting 4.1 on Java 
17. We set specific thresholds for backwards compatibility, but forward 
compatibility IMO should be indefinite for any supported release (i.e. 
currently 4.1 and newer).

I would've still voted +1 for the release (assuming we'd handle Gradle in 
4.1.2), but we also have that issue with Modeler (also Java 17 related) I 
mentioned in another message. So I am -1 for now, unless someone proves me 
wrong on the Windows Modeler issue :)

Andrus


> On Dec 16, 2021, at 1:31 PM, Nikita Timofeev  
> wrote:
> 
> 
> There's no general support for the JDK 17 in the 4.1 branch, only Modeler is 
> updated. Full support for the 17 is in the 4.2 branch.
> Not sure is it worth the effort to bring everything to the 4.1.


> Thursday, 16 December 2021, 02:07pm +03:00 from Aristedes Maniatis  
> a...@ish.com.au.invalid :
> 
>> Its just that gradle 7 is needed to work with Java 17. So if an 
>> important set of fixes for 4.1.1 is Java 17 support, that might need to 
>> come along as well.
>> 
>> Of course, that isn't essential, depending on how quickly we get to the 
>> final 4.2 release.
>> 
>> 
>> Ari
>> 
>> 
>> On 16/12/21 7:11pm, Nikita Timofeev wrote:
>> Hi Ari,
>> 
>> Gradle 7 fix is in the 4.2 version.
>> 
>> On Thu, Dec 16, 2021 at 2:53 AM Aristedes Maniatis
>> < a...@ish.com.au.invalid> wrote:
>>> Did the fixes to allow cgen to work under gradle 7 come in with this
>>> release?
>>> 
>>> 
>>> Ari
>>> 
>>> 
>>> On 16/12/21 2:22am, Nikita Timofeev wrote:
 Hi all,
 
 Here is the 4.1.1 release. There are some useful fixes, including JDK
 17 support in the Modeler.
 
 Release notes:  
 https://github.com/apache/cayenne/blob/4.1.1/RELEASE-NOTES.txt
 Maven repo:  
 https://repository.apache.org/content/repositories/orgapachecayenne-1047/
 Assemblies:  https://dist.apache.org/repos/dist/dev/cayenne/4.1.1/
 
 Please evaluate and cast your votes
 
 --
 Best regards,
 Nikita Timofeev
>> 
>> 

Re: [VOTE] Apache Cayenne 4.1.1 release

[Andrus Adamchik]

I am actually having a problem running 4.1.1 Modeler on Windows with Java 17. 
4.2.B1 starts fine, but 4.1.1 gives me the old "No suitable java version found 
on your system! The program requires Java 1.8 or later"

Thanks,
Andrus


> On Dec 15, 2021, at 5:22 PM, Nikita Timofeev  
> wrote:
> 
> Hi all,
> 
> Here is the 4.1.1 release. There are some useful fixes, including JDK
> 17 support in the Modeler.
> 
> Release notes: https://github.com/apache/cayenne/blob/4.1.1/RELEASE-NOTES.txt
> Maven repo: 
> https://repository.apache.org/content/repositories/orgapachecayenne-1047/
> Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.1.1/
> 
> Please evaluate and cast your votes
> 
> --
> Best regards,
> Nikita Timofeev

Re: UI toolkit for the future Modeler

[Andrus Adamchik]

I see a couple of problems with the current UI (beside it being subjectively 
old) : 

* We are effectively blocked from any significant evolution of the Modeler. Any 
time we want to do anything fancy (e.g. improve usability of tables with 
editable cells, etc.), we quickly run into the wall with Swing capabilities.
* JGoodies library that we depend heavily upon for layouts is no longer 
free/open source [1], creating risks for JVM upgrades. 

So modernization of the Modeler is a practical matter.

Looks like Fleet is not using Compose [2], but a lesser known JetBrains Toolbox 
does [3]. And everyone admits it is still raw.

Andrus

[1] https://www.jgoodies.com/downloads/libraries/
[2] https://twitter.com/jetbrains/status/1465245360973131777 
<https://twitter.com/jetbrains/status/1465245360973131777>
[3] 
https://blog.jetbrains.com/kotlin/2021/08/compose-multiplatform-goes-alpha/#toolbox
 
<https://blog.jetbrains.com/kotlin/2021/08/compose-multiplatform-goes-alpha/#toolbox>



> On Dec 14, 2021, at 12:48 AM, John Huss  wrote:
> 
> I believe that compose UI library is used to build the new upcoming IDE
> from JetBrains called Fleet. So I expect it will continue to be supported
> unless that product completely flops.
> 
> I don't mind the current modeler UI. It's good enough for me.
> 
> https://www.jetbrains.com/fleet/
> 
> 
> On Sat, Dec 11, 2021 at 2:15 AM Andrus Adamchik  wrote:
> 
>> A datapoint to our perennial discussion of technology to use for the
>> future CayenneModeler... With Swing being old and crusty, and JavaFX no
>> longer supported by Oracle, perhaps we should be looking for something
>> fresh. I just came across a new "Compose Multiplatform" desktop UI
>> framework by JetBrains [1]. It is programmed in Kotlin and is based on
>> Google toolkit for Android. Their GitHub examples [2] are not that visually
>> impressive, but I would imagine it is a matter of styling. A million $
>> question is whether it will be around and open source in 10-15 years.
>> 
>> Anyone knows anything about it?
>> 
>> Andrus
>> 
>> [1] https://www.jetbrains.com/lp/compose-mpp/
>> [2]
>> https://github.com/JetBrains/compose-jb/blob/master/artwork/readme/apps.png
>> 
>> 
>> 

UI toolkit for the future Modeler

[Andrus Adamchik]

A datapoint to our perennial discussion of technology to use for the future 
CayenneModeler... With Swing being old and crusty, and JavaFX no longer 
supported by Oracle, perhaps we should be looking for something fresh. I just 
came across a new "Compose Multiplatform" desktop UI framework by JetBrains 
[1]. It is programmed in Kotlin and is based on Google toolkit for Android. 
Their GitHub examples [2] are not that visually impressive, but I would imagine 
it is a matter of styling. A million $ question is whether it will be around 
and open source in 10-15 years. 

Anyone knows anything about it?

Andrus

[1] https://www.jetbrains.com/lp/compose-mpp/ 
[2] https://github.com/JetBrains/compose-jb/blob/master/artwork/readme/apps.png

Re: [VOTE] Apache Cayenne 4.2.B1 release, second try

[Andrus Adamchik]

Thanks Nikita!

I will send the announcement to user@ and Twitter. 

Now on to the bugfix release of 4.1.1 :) 

Andrus

> On Dec 6, 2021, at 4:36 PM, Nikita Timofeev  wrote:
> 
> With my +1 the result is following:
> 
> Michael Gentry (PMC): +1
> John Huss (PMC): +1
> Andrus Adamchik (PMC): +1
> Nikita Timofeev (PMC): +1
> 
> I will finish the release today.
> Thanks, everyone!
> 
> On Sun, Dec 5, 2021 at 11:53 AM Andrus Adamchik  wrote:
>> 
>> My checklist passes. Tested the Modeler on Mac[*] and Windows - it works 
>> under both Java 11 and 17.
>> 
>> +1 on the release
>> 
>> Andrus
>> 
>> [*] On MacOS under Java 17 the left side of the menu bar is darker than the 
>> right side, but everything functions properly.
>> 
>> 
>>> On Dec 1, 2021, at 6:19 PM, Nikita Timofeev  
>>> wrote:
>>> 
>>> Hi all,
>>> 
>>> Here's a new build of 4.2.B1.
>>> 
>>> Release notes: 
>>> https://github.com/apache/cayenne/blob/4.2.B1/RELEASE-NOTES.txt
>>> Maven repo: 
>>> https://repository.apache.org/content/repositories/orgapachecayenne-1046/
>>> Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.2.B1/
>>> 
>>> Please evaluate and cast your votes.
>>> 
>>> --
>>> Best regards,
>>> Nikita Timofeev
>> 
> 
> 
> -- 
> Best regards,
> Nikita Timofeev

Re: [VOTE] Apache Cayenne 4.2.B1 release, second try

[Andrus Adamchik]

My checklist passes. Tested the Modeler on Mac[*] and Windows - it works under 
both Java 11 and 17.

+1 on the release

Andrus

[*] On MacOS under Java 17 the left side of the menu bar is darker than the 
right side, but everything functions properly. 


> On Dec 1, 2021, at 6:19 PM, Nikita Timofeev  wrote:
> 
> Hi all,
> 
> Here's a new build of 4.2.B1.
> 
> Release notes: https://github.com/apache/cayenne/blob/4.2.B1/RELEASE-NOTES.txt
> Maven repo: 
> https://repository.apache.org/content/repositories/orgapachecayenne-1046/
> Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.2.B1/
> 
> Please evaluate and cast your votes.
> 
> -- 
> Best regards,
> Nikita Timofeev

Re: [VOTE] Apache Cayenne 4.2.B1 release, second try

[Andrus Adamchik]

Yeah, protostuff (third-party lib) does not support Java 17. From my 
understanding there's no way around this. 

My suggestion is to just document it, wait for an update from the authors, and 
remove ROP support from Cayenne 5.0 :) 

Andrus


> On Dec 2, 2021, at 5:20 PM, John Huss  wrote:
> 
> After correcting the gradle issue, I'm seeing these test failures on JDK
> 17.0.1:
> 
> [*INFO*] *--- *maven-surefire-plugin:2.22.2:test *(default-test)* @
> cayenne-protostuff* ---*
> 
> [*INFO*]
> 
> [*INFO*] ---
> 
> [*INFO*]  T E S T S
> 
> [*INFO*] ---
> 
> [*INFO*] Running org.apache.cayenne.configuration.rop.client.
> *ProtostuffModuleProviderTest*
> 
> [*INFO*] *Tests run: 2*, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.025 s - in org.apache.cayenne.configuration.rop.client.
> *ProtostuffModuleProviderTest*
> 
> [*INFO*] Running org.apache.cayenne.
> *ObjectContextChangeLogSubListMessageFactoryTest*
> 
> [*ERROR*] *Tests **run: 1*, Failures: 0, *Errors: 1*, Skipped: 0, Time
> elapsed: 0.038 s* <<< FAILURE!* - in org.apache.cayenne.
> *ObjectContextChangeLogSubListMessageFactoryTest*
> 
> [*ERROR*]
> testGetDiffsSerializable(org.apache.cayenne.ObjectContextChangeLogSubListMessageFactoryTest)
> Time elapsed: 0.038 s  <<< ERROR!
> 
> java.lang.ExceptionInInitializerError
> 
> at
> org.apache.cayenne.ObjectContextChangeLogSubListMessageFactoryTest.testGetDiffsSerializable(ObjectContextChangeLogSubListMessageFactoryTest.java:48)
> 
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> field private final java.lang.Object
> java.util.Collections$SingletonSet.element accessible: module java.base
> does not "opens java.util" to unnamed module @fe48b45
> 
> at
> org.apache.cayenne.ObjectContextChangeLogSubListMessageFactoryTest.testGetDiffsSerializable(ObjectContextChangeLogSubListMessageFactoryTest.java:48)
> 
> 
> [*INFO*] Running org.apache.cayenne.rop.protostuff.
> *ProtostuffROPSerializationTest*
> 
> [*ERROR*] *Tests **run: 3*, Failures: 0, *Errors: 1*, Skipped: 0, Time
> elapsed: 0.019 s* <<< FAILURE!* - in org.apache.cayenne.rop.protostuff.
> *ProtostuffROPSerializationTest*
> 
> [*ERROR*]
> testColumnQuerySerialization(org.apache.cayenne.rop.protostuff.ProtostuffROPSerializationTest)
> Time elapsed: 0.005 s  <<< ERROR!
> 
> java.lang.NoClassDefFoundError: Could not initialize class
> io.protostuff.runtime.PolymorphicCollectionSchema
> 
> at
> org.apache.cayenne.rop.protostuff.ProtostuffROPSerializationTest.testColumnQuerySerialization(ProtostuffROPSerializationTest.java:119)
> 
> 
> [*INFO*] Running org.apache.cayenne.rop.protostuff.
> *ProtostuffPersistentObjectCollectionsTest*
> 
> [*ERROR*] *Tests **run: 6*, Failures: 0, *Errors: 6*, Skipped: 0, Time
> elapsed: 0.006 s* <<< FAILURE!* - in org.apache.cayenne.rop.protostuff.
> *ProtostuffPersistentObjectCollectionsTest*
> 
> [*ERROR*]
> testPersistentObjectMapWithWrapper(org.apache.cayenne.rop.protostuff.ProtostuffPersistentObjectCollectionsTest)
> Time elapsed: 0.004 s  <<< ERROR!
> 
> java.lang.ExceptionInInitializerError
> 
> at
> org.apache.cayenne.rop.protostuff.ProtostuffPersistentObjectCollectionsTest.testPersistentObjectMapWithWrapper(ProtostuffPersistentObjectCollectionsTest.java:150)
> 
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> field private final java.lang.Object java.util.Collections$SingletonMap.k
> accessible: module java.base does not "opens java.util" to unnamed module
> @fe48b45
> 
> at
> org.apache.cayenne.rop.protostuff.ProtostuffPersistentObjectCollectionsTest.testPersistentObjectMapWithWrapper(ProtostuffPersistentObjectCollectionsTest.java:150)
> 
> 
> [*ERROR*]
> testPersistentObjectMap(org.apache.cayenne.rop.protostuff.ProtostuffPersistentObjectCollectionsTest)
> Time elapsed: 0.001 s  <<< ERROR!
> 
> java.lang.NoClassDefFoundError: Could not initialize class
> io.protostuff.runtime.PolymorphicMapSchema
> 
> at
> org.apache.cayenne.rop.protostuff.ProtostuffPersistentObjectCollectionsTest.testPersistentObjectMap(ProtostuffPersistentObjectCollectionsTest.java:134)
> 
> 
> [*ERROR*]
> testPersistentObjectSet(org.apache.cayenne.rop.protostuff.ProtostuffPersistentObjectCollectionsTest)
> Time elapsed: 0 s  <<< ERROR!
> 
> java.lang.NoClassDefFoundError: Could not initialize class
> io.protostuff.runtime.PolymorphicCollectionSchema
> 
> at
> org.apache.cayenne.rop.protostuff.ProtostuffPersistentObjectCollectionsTest.testPersistentObjectSet(ProtostuffPersistentObjectCollectionsTest.java:98)
> 
> 
> [*ERROR*]
> testPersistentObjectList(org.apache.cayenne.rop.protostuff.ProtostuffPersistentObjectCollectionsTest)
> Time elapsed: 0 s  <<< ERROR!
> 
> java.lang.NoClassDefFoundError: Could not initialize class
> io.protostuff.runtime.PolymorphicCollectionSchema
> 
> at
> 

Re: [VOTE] Apache Cayenne 4.2.B1 release

[Andrus Adamchik]

Thanks, this solved it. 

Having one more problem - starting Modeler from the Windows assembly. I tested 
a few cases:

1. Old Windows 7 VM

1.1 Java 1.8 - works
1.2 Java 17 (Temurin) - shows an error dialog: "No suitable Java version found 
on your system! The program requires Java 1.8 or later"

2. Windows 10 VM

1.1 Java 11 (Temurin) - shows an error dialog: "No suitable Java version found 
on your system! The program requires Java 1.8 or later"
CayenneModeler 4.1 starts on this VM with no issues. 


Andrus


> On Nov 29, 2021, at 12:35 PM, Nikita Timofeev  
> wrote:
> 
> Hi Andrus,
> 
> You need manually copy the "gradle" directory with all content from
> git checkout to the released sources in the "cayenne-gradle-plugin"
> module.
> This folder is just dropped completely in the src release to comply
> with the Apache guidelines.
> It's mentioned here [1] in the "Releasing Downloadable Assemblies" section.
> 
> [1] https://cayenne.apache.org/dev/release-guide.html
> 
> On Mon, Nov 29, 2021 at 1:07 PM Andrus Adamchik  wrote:
>> 
>> Trying to build from source with Java 8. Getting an error in 
>> "cayenne-gradle-plugin". I tried with both Gradle 7.3 available on the PATH, 
>> and without it. Same error. Any ideas?
>> 
>> Andrus
>> 
>> 
>> [INFO] --< org.apache.cayenne.plugins:cayenne-gradle-plugin 
>> >--
>> [INFO] Building cayenne-gradle-plugin: Cayenne Gradle Plugin 4.2.B1 
>> [22/59]
>> [INFO] [ pom 
>> ]-
>> [INFO]
>> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ 
>> cayenne-gradle-plugin ---
>> [INFO]
>> [INFO] --- maven-dependency-plugin:3.0.1:build-classpath (build-classpath) @ 
>> cayenne-gradle-plugin ---
>> [INFO] Skipped writing classpath file 
>> '/Users/andrus/Desktop/4.2.B1/cayenne-4.2.B1-src/cayenne-gradle-plugin/build/classpath.txt'.
>>   No changes found.
>> [INFO]
>> [INFO] --- exec-maven-plugin:1.6.0:exec (gradle) @ cayenne-gradle-plugin ---
>> Error: Could not find or load main class org.gradle.wrapper.GradleWrapperMain
>> [ERROR] Command execution failed.
>> org.apache.commons.exec.ExecuteException: Process exited with an error: 1 
>> (Exit value: 1)
>>at org.apache.commons.exec.DefaultExecutor.executeInternal 
>> (DefaultExecutor.java:404)
>>at org.apache.commons.exec.DefaultExecutor.execute 
>> (DefaultExecutor.java:166)
>>at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:804)
>>at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:751)
>>at org.codehaus.mojo.exec.ExecMojo.execute (ExecMojo.java:313)
>>at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
>> (DefaultBuildPluginManager.java:137)
>>at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
>> (MojoExecutor.java:210)
>>at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
>> (MojoExecutor.java:156)
>>at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
>> (MojoExecutor.java:148)
>> 
>> 
>> [INFO] cayenne-gradle-plugin: Cayenne Gradle Plugin ... FAILURE [  1.092 
>> s]
>> 
>> 
>> 
>> 
>>> On Nov 25, 2021, at 5:32 PM, Nikita Timofeev  
>>> wrote:
>>> 
>>> Hi all,
>>> 
>>> Here is a 4.2.B1 release.
>>> 
>>> Release notes: 
>>> https://github.com/apache/cayenne/blob/4.2.B1/RELEASE-NOTES.txt
>>> Maven repo: 
>>> https://repository.apache.org/content/repositories/orgapachecayenne-1045/
>>> Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.2.B1/
>>> 
>>> Please evaluate and cast your votes.
>>> 
>>> --
>>> Best regards,
>>> Nikita Timofeev
>> 
> 
> 
> -- 
> Best regards,
> Nikita Timofeev

Re: [VOTE] Apache Cayenne 4.2.B1 release

[Andrus Adamchik]

Trying to build from source with Java 8. Getting an error in 
"cayenne-gradle-plugin". I tried with both Gradle 7.3 available on the PATH, 
and without it. Same error. Any ideas?

Andrus


[INFO] --< org.apache.cayenne.plugins:cayenne-gradle-plugin >--
[INFO] Building cayenne-gradle-plugin: Cayenne Gradle Plugin 4.2.B1 [22/59]
[INFO] [ pom ]-
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ cayenne-gradle-plugin 
---
[INFO] 
[INFO] --- maven-dependency-plugin:3.0.1:build-classpath (build-classpath) @ 
cayenne-gradle-plugin ---
[INFO] Skipped writing classpath file 
'/Users/andrus/Desktop/4.2.B1/cayenne-4.2.B1-src/cayenne-gradle-plugin/build/classpath.txt'.
  No changes found.
[INFO] 
[INFO] --- exec-maven-plugin:1.6.0:exec (gradle) @ cayenne-gradle-plugin ---
Error: Could not find or load main class org.gradle.wrapper.GradleWrapperMain
[ERROR] Command execution failed.
org.apache.commons.exec.ExecuteException: Process exited with an error: 1 (Exit 
value: 1)
at org.apache.commons.exec.DefaultExecutor.executeInternal 
(DefaultExecutor.java:404)
at org.apache.commons.exec.DefaultExecutor.execute 
(DefaultExecutor.java:166)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:804)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:751)
at org.codehaus.mojo.exec.ExecMojo.execute (ExecMojo.java:313)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
(DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:148)


[INFO] cayenne-gradle-plugin: Cayenne Gradle Plugin ... FAILURE [  1.092 s]




> On Nov 25, 2021, at 5:32 PM, Nikita Timofeev  
> wrote:
> 
> Hi all,
> 
> Here is a 4.2.B1 release.
> 
> Release notes: https://github.com/apache/cayenne/blob/4.2.B1/RELEASE-NOTES.txt
> Maven repo: 
> https://repository.apache.org/content/repositories/orgapachecayenne-1045/
> Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.2.B1/
> 
> Please evaluate and cast your votes.
> 
> -- 
> Best regards,
> Nikita Timofeev

Re: Cayenne Modeler on macOS Monterey

[Andrus Adamchik]

Yeah, when you run it manually from the shell, you select which JDK to use. 
When you start from Desktop, it depends on the native wrapper logic. 

BTW, just found the Jira and the mailing list discussion:


* https://issues.apache.org/jira/browse/CAY-2721 
<https://issues.apache.org/jira/browse/CAY-2721>
* https://lists.apache.org/thread/p90898fsbjq6fv2lwvsw6vv1prob5ycr

Andrus

> On Nov 17, 2021, at 8:24 PM, Michael Gentry  wrote:
> 
> Oh, I meant to mention that the about dialog says it is using OpenJDK 1.8,
> but I suppose I only see that in the JAR version.
> 
> I do have JDK 17 installed, so perhaps that is it.
> 
> Thanks!
> 
> 
> On Wed, Nov 17, 2021 at 1:10 PM Andrus Adamchik  wrote:
> 
>> Hi Mike,
>> 
>> There's an issue with Java 17 and native Modeler components. Nikita is
>> testing a fix.
>> 
>> So your problem is likely unrelated to Monterey.
>> 
>> Andrus
>> 
>> 
>>> On Nov 17, 2021, at 7:51 PM, Michael Gentry  wrote:
>>> 
>>> Has anyone tried running Cayenne Modeler on macOS Monterey?
>>> 
>>> I ran, or at least I tried, CM 4.2M3 to look at Lon's issue and CM
>> wouldn't
>>> run. Tried a version I downloaded from the web site and the version I
>> built
>>> previously for the 4.2M3 release cycle. Didn't see any messages in
>>> Console.app, but I didn't try to find other logs. I know the version I
>>> built previously ran on Big Sur at the time, otherwise I wouldn't
>>> have +1'ed it.
>>> 
>>> Running the generic JAR works.
>>> 
>>> Thanks,
>>> 
>>> mrg
>> 
>> 

Re: Cayenne Modeler on macOS Monterey

[Andrus Adamchik]

Hi Mike,

There's an issue with Java 17 and native Modeler components. Nikita is testing 
a fix. 

So your problem is likely unrelated to Monterey. 

Andrus


> On Nov 17, 2021, at 7:51 PM, Michael Gentry  wrote:
> 
> Has anyone tried running Cayenne Modeler on macOS Monterey?
> 
> I ran, or at least I tried, CM 4.2M3 to look at Lon's issue and CM wouldn't
> run. Tried a version I downloaded from the web site and the version I built
> previously for the 4.2M3 release cycle. Didn't see any messages in
> Console.app, but I didn't try to find other logs. I know the version I
> built previously ran on Big Sur at the time, otherwise I wouldn't
> have +1'ed it.
> 
> Running the generic JAR works.
> 
> Thanks,
> 
> mrg

Re: CI

[Andrus Adamchik]

How good is buildbot? Is it capable of running dockerized builds? Does it have 
MacOS and Windows agents?

My (uninformed) vote is to abandon buildbot and stay on Travis. When/if it 
becomes untenable, migrate to GitHub Actions outside Apache GitHub (or maybe 
within Apache if GA restrictions are removed).

Automating release artifacts is a good idea. But probably not until we are more 
confident in our CI infrastructure.

Andrus



> On Oct 14, 2021, at 8:20 AM, Aristedes Maniatis  
> wrote:
> 
> Should we migrate the buildbot builder on Apache infrastructure over to git 
> and get it working again? Or should we put more effort into Travis and just 
> abandon the Apache builder?
> 
> Are the new limits at Travis going to work for us?
> 
> I think we'll be more able to set up different database containers at Travis 
> rather than at Apache.
> 
> 
> Are we happy with creating release artifacts:
> 
> a. as we do today, built on a local developer machine
> b. from Travis
> c. from buildbot
> 
> 
> https://issues.apache.org/jira/browse/INFRA-22396
> 
> 
> Ari
> 
> 
> On 10/10/21 6:38pm, Andrus Adamchik wrote:
>> Oops. I guess we shouldn't jump to GA just yet.
>> 
>>> On Oct 10, 2021, at 10:28 AM, Nikita Timofeev  
>>> wrote:
>>> 
>>> 
>>> Hi all,
>>> I've read about limitations on the Apache side. It turns out not so great 
>>> in that case. There's only approved actions available and, more important, 
>>> there's limited number of runners available for *all* Apache projects. Ifra 
>>> warns that it could be really slow [1]
>>> [1] 
>>> https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=173085013#content/view/173085013
>>>  Sunday, 10 October 2021, 10:10am +03:00 from Andrus Adamchik  
>>> aadamc...@gmail.com :
>>> 
>>>> [1]  https://github.com/ishgroup/oncourse/actions
>>>> 
>>>> 
>>>> Nice! FWIW Bootique is using Github Actions for its dozens of modules, 
>>>> including cross-DB tests. A huge improvement over Travis.
>>>> 
>>>> However a bit more limited with regard to database choices.
>>>> We can run tests against any database that has a Docker image. SQLServer 
>>>> does. (We should also switch to Testcontainers for managing dockerized 
>>>> tested services, but that's a separate discussion and does not affect a 
>>>> CI/CD choice).
>>>> 
>>>> Aurora is cloud-based of course, so we'll need to program provisioning the 
>>>> test DB ourselves, but as long as a build agent has internet access, this 
>>>> should be doable.
>>>> 
>>>> Are we limited at all within the Apache project with how we can configure 
>>>> Actions?
>>>> 
>>>> Haven't tried it, good question. I hope not and it is all straight GitHub.
>>>> 
>>>> Andrus
>>>> 
>>>> 
>>>> On Oct 10, 2021, at 9:59 AM, Aristedes Maniatis < a...@ish.com.au.INVALID> 
>>>> wrote:
>>>> 
>>>> On 10/10/21 5:26pm, Andrus Adamchik wrote:
>>>>> BTW, we should probably move to Github Actions for CI/CD. Much faster 
>>>>> than Travis.
>>>> I've got a bit of experience [1] with github actions in some of my other 
>>>> open source projects, and mostly they are very good. Ties in nicely with 
>>>> pull requests as well. However a bit more limited with regard to database 
>>>> choices. Ideally we'd want databases like SQL Server, AWS Aurora, etc in 
>>>> our test suite.
>>>> 
>>>> Are we limited at all within the Apache project with how we can configure 
>>>> Actions?
>>>> 
>>>> Ari
>>>> 
>>>> 
>>>> [1]  https://github.com/ishgroup/oncourse/actions
>>>> 
> 

Re: cgen into the future

[Andrus Adamchik]

> I don't see the benefit in storing the output of generated code in version 
> control.

There's no benefit, but there's no downside either. I barely give it a thought 
during my daily work. Entity removal is probably the only snag, but it is not 
completely addressed by not having superclasses in VC: you still have to remove 
you subclass manually.

> With the configuration in our gradle build file there is absolutely nothing 
> to ask new developers to do.

Yep. This is why it was recommended by us before it got moved to the Modeler. 
Now the "Modeler-only" flow is at the same (or arguably higher) level of 
convenience.

> But I'd be equally happy for Modeler and cgen to share the same configuration 
> somewhere.

I don't remember if they can already share the config from the map.xml file. 
But they definitely should.



I expected tools removal to be a controversial proposal. Still decided to throw 
it out there. I am always looking for opportunities to minimize our support 
footprint (hi, ROP :)). Properly maintaining the tools across 3 build systems 
is a non-trivial effort (especially Gradle, due to the rest of Cayenne being 
built with Maven). Now we've only increased the footprint, as we'd need to be 
merging map.xml config with build file config. But of course I realize that 
lots of people have designed their Cayenne workflow around the build tools (and 
we encouraged it), and will not appreciate them being taken away. 

FWIW, the switch was very simple for me and my team, but that may be because 
"cdbimport" was also in use, and going from pom.xml to the Modeler for 
cdbimport removed so much pain, that it was a no-brainer. "cgen" was just icing 
on the cake. We are using standard templates and nobody cared about the latter 
one way or another (and we already had _Xyz.java under version control).

Andrus


> On Oct 10, 2021, at 11:41 AM, Aristedes Maniatis  
> wrote:
> 
> I don't see the benefit in storing the output of generated code in version 
> control. It makes commit history more noisy and hard to read without any real 
> benefit. For just this one project, that includes:
> 
> * Cayenne
> * Swagger
> * Antlr
> 
> So if someone makes a change to the data model of one of those things and 
> forgets to commit additional files, or there is a lot of boilerplate output 
> changes because (say) Swagger was updated, then things might get out of sync 
> and cause oddness in builds.
> 
> Mostly importantly, its really easy to mess up when you remove an entity from 
> Cayenne and there is no automated process which also removes the relevant 
> superclass. You may not even notice for a while until something unexpected 
> happens three months later.
> 
> With the configuration in our gradle build file there is absolutely nothing 
> to ask new developers to do. But I'd be equally happy for Modeler and cgen to 
> share the same configuration somewhere.
> 
> 
> Ari
> 
> 
> On 10/10/21 6:25pm, Andrus Adamchik wrote:
>>> We don't store generated superclasses in version control since that's 
>>> confusing and redundant.
>> I commit generated superclasses to Git everywhere. Never caused any issues 
>> that I can remember. But yes, I think that would be a prerequisite to 
>> switching away from cgen in build scripts to the Modeler-based flow.
>> 
>> What I was alluding to is that the XML config below is now managed visually 
>> in the Modeler and is saved in the XYZ.map.xml, while previously it was only 
>> saved in the local modeler preferences. So keeping a similar configuration 
>> in a build script was a superior approach because it was the only way to 
>> keep the config portable across dev machines. Imagine asking all your team 
>> members to manually import a custom template and setup their Modeler to use 
>> it for a specific project. Now this problem is gone.
>> 
>> 
>> http://cayenne.apache.org/schema/10/dbimport;>
>>  
>>  
>>  ma_.*
>>  
>>  media
>>  
>>  
>>  TABLE
>>  VIEW
>>  
>>  false
>>  false
>>  
>> org.apache.cayenne.dbsync.naming.DefaultObjectNameGenerator
>>  false
>>  false
>>  ^ma_
>>  false
>>  true
>> 
>> http://cayenne.apache.org/schema/10/cgen;>
>>  ../../../../../../java
>>  entity
>>  templates/v4_1/subclass.vm
>>  templates/v4_1/superclass.vm
>>  *.java
>>  true
>>  true
>>  false
>>  false
>>  false
>>  false
>> 
>> 
>> Andrus
>> 
>> 
>>>

Re: CI

[Andrus Adamchik]

Oops. I guess we shouldn't jump to GA just yet.

> On Oct 10, 2021, at 10:28 AM, Nikita Timofeev  
> wrote:
> 
> 
> Hi all,
> I've read about limitations on the Apache side. It turns out not so great in 
> that case. There's only approved actions available and, more important, 
> there's limited number of runners available for *all* Apache projects. Ifra 
> warns that it could be really slow [1]
> [1] 
> https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=173085013#content/view/173085013
>  Sunday, 10 October 2021, 10:10am +03:00 from Andrus Adamchik  
> aadamc...@gmail.com :
> 
>> 
>> [1]  https://github.com/ishgroup/oncourse/actions
>> 
>> 
>> Nice! FWIW Bootique is using Github Actions for its dozens of modules, 
>> including cross-DB tests. A huge improvement over Travis.
>> 
>> However a bit more limited with regard to database choices.
>> We can run tests against any database that has a Docker image. SQLServer 
>> does. (We should also switch to Testcontainers for managing dockerized 
>> tested services, but that's a separate discussion and does not affect a 
>> CI/CD choice).
>> 
>> Aurora is cloud-based of course, so we'll need to program provisioning the 
>> test DB ourselves, but as long as a build agent has internet access, this 
>> should be doable.
>> 
>> Are we limited at all within the Apache project with how we can configure 
>> Actions?
>> 
>> Haven't tried it, good question. I hope not and it is all straight GitHub.
>> 
>> Andrus
>> 
>> 
>> On Oct 10, 2021, at 9:59 AM, Aristedes Maniatis < a...@ish.com.au.INVALID> 
>> wrote:
>> 
>> On 10/10/21 5:26pm, Andrus Adamchik wrote:
>>> BTW, we should probably move to Github Actions for CI/CD. Much faster than 
>>> Travis.
>> 
>> I've got a bit of experience [1] with github actions in some of my other 
>> open source projects, and mostly they are very good. Ties in nicely with 
>> pull requests as well. However a bit more limited with regard to database 
>> choices. Ideally we'd want databases like SQL Server, AWS Aurora, etc in our 
>> test suite.
>> 
>> Are we limited at all within the Apache project with how we can configure 
>> Actions?
>> 
>> Ari
>> 
>> 
>> [1]  https://github.com/ishgroup/oncourse/actions
>> 

Re: cgen into the future

[Andrus Adamchik]

> We don't store generated superclasses in version control since that's 
> confusing and redundant.

I commit generated superclasses to Git everywhere. Never caused any issues that 
I can remember. But yes, I think that would be a prerequisite to switching away 
from cgen in build scripts to the Modeler-based flow.

What I was alluding to is that the XML config below is now managed visually in 
the Modeler and is saved in the XYZ.map.xml, while previously it was only saved 
in the local modeler preferences. So keeping a similar configuration in a build 
script was a superior approach because it was the only way to keep the config 
portable across dev machines. Imagine asking all your team members to manually 
import a custom template and setup their Modeler to use it for a specific 
project. Now this problem is gone.


http://cayenne.apache.org/schema/10/dbimport;>


ma_.*

media


TABLE
VIEW

false
false

org.apache.cayenne.dbsync.naming.DefaultObjectNameGenerator
false
false
^ma_
false
true

http://cayenne.apache.org/schema/10/cgen;>
../../../../../../java
entity
templates/v4_1/subclass.vm
templates/v4_1/superclass.vm
*.java
true
true
false
false
false
false


Andrus


> On Oct 10, 2021, at 10:04 AM, Aristedes Maniatis  
> wrote:
> 
> 
> 
> On 10/10/21 5:42pm, Andrus Adamchik wrote:
>> A bit OT... Before 4.1 all my projects used cgen and most - cdbimport. Not 
>> anymore. Things went full circle and Modeler has become the only way to sync 
>> up project with the DB. DataMap XML file now stores all the settings of the 
>> c* tasks. So now I came to realization that putting those same settings in 
>> your build file (Ant/Maven/Gradle) was simply a hack that allowed to share 
>> and version-control task configs. It is not needed anymore.
>> 
>> While I'll expect pushback on this:)  , may I suggest to deprecate the tools 
>> in 5.0, and remove them in 5.1.
> 
> Can you explain a bit more? We don't store generated superclasses in version 
> control since that's confusing and redundant. [1]  This is similar to how we 
> don't store swagger generated classes in version control for the server side 
> API implementation.
> 
> 
> Ari
> 
> 
> [1] https://github.com/ishgroup/oncourse/blob/main/server/build.gradle#L335
> [2] https://github.com/ishgroup/oncourse/blob/main/server-api/build.gradle#L62

Re: CI

[Andrus Adamchik]

> [1] https://github.com/ishgroup/oncourse/actions


Nice! FWIW Bootique is using Github Actions for its dozens of modules, 
including cross-DB tests. A huge improvement over Travis.

> However a bit more limited with regard to database choices.

We can run tests against any database that has a Docker image. SQLServer does. 
(We should also switch to Testcontainers for managing dockerized tested 
services, but that's a separate discussion and does not affect a CI/CD choice).

Aurora is cloud-based of course, so we'll need to program provisioning the test 
DB ourselves, but as long as a build agent has internet access, this should be 
doable.

> Are we limited at all within the Apache project with how we can configure 
> Actions?

Haven't tried it, good question. I hope not and it is all straight GitHub.

Andrus


> On Oct 10, 2021, at 9:59 AM, Aristedes Maniatis  
> wrote:
> 
> On 10/10/21 5:26pm, Andrus Adamchik wrote:
>> BTW, we should probably move to Github Actions for CI/CD. Much faster than 
>> Travis.
> 
> I've got a bit of experience [1] with github actions in some of my other open 
> source projects, and mostly they are very good. Ties in nicely with pull 
> requests as well. However a bit more limited with regard to database choices. 
> Ideally we'd want databases like SQL Server, AWS Aurora, etc in our test 
> suite.
> 
> Are we limited at all within the Apache project with how we can configure 
> Actions?
> 
> Ari
> 
> 
> [1] https://github.com/ishgroup/oncourse/actions

Re: Cayenne Modeler support for JDK 17

[Andrus Adamchik]

> Perhaps it would be a good opportunity to release 4.2 once the few JDK17 
> things are fixed. I think its pretty important to have a working 17 release 
> ASAP given that an increasing number of developers will be trying out this 
> upgrade.

Absolutely! Once Java 17 compatibility is addressed we should do the next 4.2 
release (as well as 4.0.x and 4.1.x).

> Anyhow, my thoughts are that the next release might be 4.2RC1, aiming for a 
> final release this year with JDK17 compatibility as a key reason for users to 
> upgrade.

I was thinking the next release should be 4.2.B1 just to follow the tradition. 
But if we don't have any stability issues during the beta, we can go final 
skipping RC phase. WDYT?

> We'd need to wait for Gradle 7.3 first I think, since it will be important to 
> test the fixes to the cgen plugin there once gradle itself becomes JDK17 
> compatible. The latest release (4.2M3) of cgen doesn't work with gradle 7+. 
> Groovy 3.0.8 is also the first groovy version to support JDK17.

A bit OT... Before 4.1 all my projects used cgen and most - cdbimport. Not 
anymore. Things went full circle and Modeler has become the only way to sync up 
project with the DB. DataMap XML file now stores all the settings of the c* 
tasks. So now I came to realization that putting those same settings in your 
build file (Ant/Maven/Gradle) was simply a hack that allowed to share and 
version-control task configs. It is not needed anymore.

While I'll expect pushback on this :) , may I suggest to deprecate the tools in 
5.0, and remove them in 5.1.


> I've asked Infra to take a look at the old buildbot builder still pointing at 
> the svn version of Cayenne [1]

I wonder if we still need buildbot. While Travis has recently fallen off a 
cliff, GitHub Actions are very capable and well-understood.

Andrus


> On Oct 10, 2021, at 9:01 AM, Aristedes Maniatis  
> wrote:
> 
> I know I haven't been around much recently to help out. Hi everyone!!!
> 
> Perhaps it would be a good opportunity to release 4.2 once the few JDK17 
> things are fixed. I think its pretty important to have a working 17 release 
> ASAP given that an increasing number of developers will be trying out this 
> upgrade.
> 
> We'd need to wait for Gradle 7.3 first I think, since it will be important to 
> test the fixes to the cgen plugin there once gradle itself becomes JDK17 
> compatible. The latest release (4.2M3) of cgen doesn't work with gradle 7+. 
> Groovy 3.0.8 is also the first groovy version to support JDK17.
> 
> Anyhow, my thoughts are that the next release might be 4.2RC1, aiming for a 
> final release this year with JDK17 compatibility as a key reason for users to 
> upgrade.
> 
> 
> I've asked Infra to take a look at the old buildbot builder still pointing at 
> the svn version of Cayenne [1]
> 
> 
> Ari
> 
> 
> 
> [1] https://issues.apache.org/jira/browse/INFRA-22396
> 
> 
> 
> On 27/9/21 5:53pm, Andrus Adamchik wrote:
>> Ok, here is the Jira: https://issues.apache.org/jira/browse/CAY-2721 
>> <https://issues.apache.org/jira/browse/CAY-2721>
>> 
>> I also described a few workarounds until we fix it.
>> 
>> Andrus
>> 
>> 
>>> On Sep 27, 2021, at 8:38 AM, Andrus Adamchik  wrote:
>>> 
>>> Yep, after installing java 17 (Temurin from https://adoptium.net/ 
>>> <https://adoptium.net/> ), Modeler would no longer start. We'll need to 
>>> investigate.
>>> 
>>> Andrus
>>> 
>>>> On Sep 24, 2021, at 6:01 PM, John Huss >>> <mailto:johnth...@gmail.com>> wrote:
>>>> 
>>>> Cayenne Modeler crashes on launch with JDK 17 (from Oracle). Here is the
>>>> output:
>>>> 
>>>> /A/C/C/MacOS> *./CayenneModeler *
>>>> 
>>>> 2021-09-24 09:50:12.418 defaults[76618:3072366]
>>>> 
>>>> The domain/default pair of (kCFPreferencesAnyApplication, AppleLocale) does
>>>> not exist
>>>> 
>>>> ./CayenneModeler: line 310: [: ==: unary operator expected
>>>> 
>>>> ./CayenneModeler: line 310: [: ==: unary operator expected
>>>> 
>>>> Exception in thread "main" java.lang.IllegalAccessError: class
>>>> org.apache.cayenne.modeler.osx.OSXPlatformInitializer (in unnamed module
>>>> @0x755c9148) cannot access class com.apple.eawt.Application (in module
>>>> java.desktop) because module java.desktop does not export com.apple.eawt to
>>>> unnamed module @0x755c9148
>>>> 
>>>> at
>>>> org.apache.cayenne.modeler.osx.OSXPlatformInitializer.initLookAndFeel(OSXPlatformInitializer.java:58)
>>

Re: snapshot releases

[Andrus Adamchik]

Hi Ari, 

Snapshots are published to the Apache snapshots repo at 
https://repository.apache.org/content/repositories/snapshots 
. Central does 
not allow to host snapshots:



apache-releases
Apache Release Distribution Repository

https://repository.apache.org/service/local/staging/deploy/maven2


apache.snapshots.https
Apache Development Snapshot Repository
https://repository.apache.org/content/repositories/snapshots




> I can see Travis is building them: 
> https://app.travis-ci.com/github/apache/cayenne/jobs/537003205

BTW, we should probably move to Github Actions for CI/CD. Much faster than 
Travis.

Andrus


> On Oct 10, 2021, at 9:01 AM, Aristedes Maniatis  
> wrote:
> 
> I can see Travis is building them: 
> https://app.travis-ci.com/github/apache/cayenne/jobs/537003205
> 
> But where do they go? I can't find them on Maven Central.
> 
> 
> Cheers
> Ari

Re: Cayenne Modeler support for JDK 17

[Andrus Adamchik]

Ok, here is the Jira: https://issues.apache.org/jira/browse/CAY-2721 
<https://issues.apache.org/jira/browse/CAY-2721>

I also described a few workarounds until we fix it.

Andrus


> On Sep 27, 2021, at 8:38 AM, Andrus Adamchik  wrote:
> 
> Yep, after installing java 17 (Temurin from https://adoptium.net/ 
> <https://adoptium.net/> ), Modeler would no longer start. We'll need to 
> investigate. 
> 
> Andrus
> 
>> On Sep 24, 2021, at 6:01 PM, John Huss > <mailto:johnth...@gmail.com>> wrote:
>> 
>> Cayenne Modeler crashes on launch with JDK 17 (from Oracle). Here is the
>> output:
>> 
>> /A/C/C/MacOS> *./CayenneModeler *
>> 
>> 2021-09-24 09:50:12.418 defaults[76618:3072366]
>> 
>> The domain/default pair of (kCFPreferencesAnyApplication, AppleLocale) does
>> not exist
>> 
>> ./CayenneModeler: line 310: [: ==: unary operator expected
>> 
>> ./CayenneModeler: line 310: [: ==: unary operator expected
>> 
>> Exception in thread "main" java.lang.IllegalAccessError: class
>> org.apache.cayenne.modeler.osx.OSXPlatformInitializer (in unnamed module
>> @0x755c9148) cannot access class com.apple.eawt.Application (in module
>> java.desktop) because module java.desktop does not export com.apple.eawt to
>> unnamed module @0x755c9148
>> 
>> at
>> org.apache.cayenne.modeler.osx.OSXPlatformInitializer.initLookAndFeel(OSXPlatformInitializer.java:58)
>> 
>> at org.apache.cayenne.modeler.Main.launch(Main.java:74)
>> 
>> at org.apache.cayenne.modeler.osx.OSXMain.main(OSXMain.java:37)
>> 
>> The shell script problems on line 310 are due to the way the java version
>> number is reported and are fixed by updating the newest version of the
>> launcher here:
>> https://raw.githubusercontent.com/tofi86/universalJavaApplicationStub/master/src/universalJavaApplicationStub
>>  
>> <https://raw.githubusercontent.com/tofi86/universalJavaApplicationStub/master/src/universalJavaApplicationStub>
>> 
>> But it still crashes due to the module access problem.
>> 
>> ---
>> 
>> Besides that crash, I am seeing a build failure with the new JDK 17. It
>> looks like groovy may need to be updated to support compiling with JDK 17.
>> 
>> 
>> org.apache.cayenne.tools.DbGenerateTaskIT > defaultConfigTaskSuccess FAILED
>> 
>>org.gradle.testkit.runner.UnexpectedBuildFailure at
>> DbGenerateTaskIT.java:65
>> 
>> 
>> [*INFO*] cayenne-gradle-plugin: Cayenne Gradle Plugin ... *FAILURE* [
>> 20.426 s]
>> 
>> java.lang.IllegalArgumentException: Unsupported class file major version 61
>>  at groovyjarjarasm.asm.ClassReader.(ClassReader.java:189)
>>  at groovyjarjarasm.asm.ClassReader.(ClassReader.java:170)
>>  at groovyjarjarasm.asm.ClassReader.(ClassReader.java:156)
>>  at groovyjarjarasm.asm.ClassReader.(ClassReader.java:277)
>>  at 
>> org.codehaus.groovy.ast.decompiled.AsmDecompiler.parseClass(AsmDecompiler.java:81)
>>  at 
>> org.codehaus.groovy.control.ClassNodeResolver.findDecompiled(ClassNodeResolver.java:251)
>>  at 
>> org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(ClassNodeResolver.java:189)
>>  at 
>> org.codehaus.groovy.control.ClassNodeResolver.findClassNode(ClassNodeResolver.java:169)
>>  at 
>> org.codehaus.groovy.control.ClassNodeResolver.resolveName(ClassNodeResolver.java:125)
>>  at 
>> org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveClassNullable(AsmReferenceResolver.java:57)
>>  at 
>> org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveClass(AsmReferenceResolver.java:44)
>>  at 
>> org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveNonArrayType(AsmReferenceResolver.java:79)
>>  at 
>> org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveType(AsmReferenceResolver.java:70)
>>  at 
>> org.codehaus.groovy.ast.decompiled.MemberSignatureParser.createMethodNode(MemberSignatureParser.java:57)
>>  at 
>> org.codehaus.groovy.ast.decompiled.DecompiledClassNode.lambda$createMethodNode$1(DecompiledClassNode.java:230)
>>  at 
>> org.codehaus.groovy.ast.decompiled.DecompiledClassNode.createMethodNode(DecompiledClassNode.java:236)
>>  at 
>> org.codehaus.groovy.ast.decompiled.DecompiledClassNode.lazyInitMembers(DecompiledClassNode.java:203)
>>  at 
>> org.codehaus.groovy.ast.decompiled.DecompiledClassNode.getDeclaredMet

Re: Cayenne Modeler support for JDK 17

[Andrus Adamchik]

Yep, after installing java 17 (Temurin from https://adoptium.net/ 
 ), Modeler would no longer start. We'll need to 
investigate. 

Andrus

> On Sep 24, 2021, at 6:01 PM, John Huss  wrote:
> 
> Cayenne Modeler crashes on launch with JDK 17 (from Oracle). Here is the
> output:
> 
> /A/C/C/MacOS> *./CayenneModeler *
> 
> 2021-09-24 09:50:12.418 defaults[76618:3072366]
> 
> The domain/default pair of (kCFPreferencesAnyApplication, AppleLocale) does
> not exist
> 
> ./CayenneModeler: line 310: [: ==: unary operator expected
> 
> ./CayenneModeler: line 310: [: ==: unary operator expected
> 
> Exception in thread "main" java.lang.IllegalAccessError: class
> org.apache.cayenne.modeler.osx.OSXPlatformInitializer (in unnamed module
> @0x755c9148) cannot access class com.apple.eawt.Application (in module
> java.desktop) because module java.desktop does not export com.apple.eawt to
> unnamed module @0x755c9148
> 
> at
> org.apache.cayenne.modeler.osx.OSXPlatformInitializer.initLookAndFeel(OSXPlatformInitializer.java:58)
> 
> at org.apache.cayenne.modeler.Main.launch(Main.java:74)
> 
> at org.apache.cayenne.modeler.osx.OSXMain.main(OSXMain.java:37)
> 
> The shell script problems on line 310 are due to the way the java version
> number is reported and are fixed by updating the newest version of the
> launcher here:
> https://raw.githubusercontent.com/tofi86/universalJavaApplicationStub/master/src/universalJavaApplicationStub
> 
> But it still crashes due to the module access problem.
> 
> ---
> 
> Besides that crash, I am seeing a build failure with the new JDK 17. It
> looks like groovy may need to be updated to support compiling with JDK 17.
> 
> 
> org.apache.cayenne.tools.DbGenerateTaskIT > defaultConfigTaskSuccess FAILED
> 
>org.gradle.testkit.runner.UnexpectedBuildFailure at
> DbGenerateTaskIT.java:65
> 
> 
> [*INFO*] cayenne-gradle-plugin: Cayenne Gradle Plugin ... *FAILURE* [
> 20.426 s]
> 
> java.lang.IllegalArgumentException: Unsupported class file major version 61
>   at groovyjarjarasm.asm.ClassReader.(ClassReader.java:189)
>   at groovyjarjarasm.asm.ClassReader.(ClassReader.java:170)
>   at groovyjarjarasm.asm.ClassReader.(ClassReader.java:156)
>   at groovyjarjarasm.asm.ClassReader.(ClassReader.java:277)
>   at 
> org.codehaus.groovy.ast.decompiled.AsmDecompiler.parseClass(AsmDecompiler.java:81)
>   at 
> org.codehaus.groovy.control.ClassNodeResolver.findDecompiled(ClassNodeResolver.java:251)
>   at 
> org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(ClassNodeResolver.java:189)
>   at 
> org.codehaus.groovy.control.ClassNodeResolver.findClassNode(ClassNodeResolver.java:169)
>   at 
> org.codehaus.groovy.control.ClassNodeResolver.resolveName(ClassNodeResolver.java:125)
>   at 
> org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveClassNullable(AsmReferenceResolver.java:57)
>   at 
> org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveClass(AsmReferenceResolver.java:44)
>   at 
> org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveNonArrayType(AsmReferenceResolver.java:79)
>   at 
> org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveType(AsmReferenceResolver.java:70)
>   at 
> org.codehaus.groovy.ast.decompiled.MemberSignatureParser.createMethodNode(MemberSignatureParser.java:57)
>   at 
> org.codehaus.groovy.ast.decompiled.DecompiledClassNode.lambda$createMethodNode$1(DecompiledClassNode.java:230)
>   at 
> org.codehaus.groovy.ast.decompiled.DecompiledClassNode.createMethodNode(DecompiledClassNode.java:236)
>   at 
> org.codehaus.groovy.ast.decompiled.DecompiledClassNode.lazyInitMembers(DecompiledClassNode.java:203)
>   at 
> org.codehaus.groovy.ast.decompiled.DecompiledClassNode.getDeclaredMethods(DecompiledClassNode.java:122)
>   at 
> org.codehaus.groovy.ast.ClassNode.tryFindPossibleMethod(ClassNode.java:1283)
>   at 
> org.codehaus.groovy.control.StaticImportVisitor.transformMethodCallExpression(StaticImportVisitor.java:251)
>   at 
> org.codehaus.groovy.control.StaticImportVisitor.transform(StaticImportVisitor.java:133)
>   at 
> org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitExpressionStatement(ClassCodeExpressionTransformer.java:108)
>   at 
> org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
>   at 
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:138)
>   at 
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:111)
>   at 
> org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitConstructorOrMethod(ClassCodeExpressionTransformer.java:66)
>   at 
> org.codehaus.groovy.control.StaticImportVisitor.visitConstructorOrMethod(StaticImportVisitor.java:108)
>   at 

Re: [VOTE] Apache Cayenne 4.2.M3 release

[Andrus Adamchik]

> On Jun 9, 2021, at 12:53 PM, Justin Mclean  wrote:
> 
>> 
>> I don't see anything about including LICENSE/NOTICE in .jar files anymore 
>> (we do include them). 
> 
> Yep that still needed last I looked.

Makes sense. Also since the rule is "license must match what's in the 
artifact", we should package the *source* LICENSE in the individual jars. 

Andrus

Re: [VOTE] Apache Cayenne 4.2.M3 release

[Andrus Adamchik]

Interesting. Being Apache old-timers, we haven't reviewed the LICENSE/NOTICE 
requirements in a bit. So looks like we may need 2 separate LICENSE files for 
source and binary distros:

1. The source one should exclude the following licenses: CAUCHO, JGOODIES, 
OGNL, VPP, jEdit Syntax, Inflector (did we borrow any inflector sources?), 
JGraph, SLF4J, EPL.

2. Binary one should exclude EPL (I still don't believe we have any EPL 
dependencies; maybe the original one came from our attempts to develop an 
Eclipse plugin?).

I don't see anything about including LICENSE/NOTICE in .jar files anymore (we 
do include them). Suppose a standalone jar may be considered a special kind of 
a "binary release". Any ideas?

Andrus 


> On Jun 8, 2021, at 11:04 AM, Justin Mclean  wrote:
> 
> Hi,
> 
> Having a dependancy on something that EPL is 100% OK, but if it is only a 
> dependancy you then don’t need to list it in your LICENSE file. [1] Only 
> things that are in the source release artefact need to be mentioned in 
> LICENSE.
> 
> Kind Regards,
> Justin
> 
> 1. https://infra.apache.org/licensing-howto.html#guiding

Re: [VOTE] Apache Cayenne 4.2.M3 release

[Andrus Adamchik]

Hi Justin,

Thanks for catching these issues. I think #2 is simply a bug in the build 
script ("cayenne-gradle-plugin/build" is in ".gitignore" and is clearly copied 
to the distro by mistake). Need to fix it.

#1 is something I have no recollection of... EPL is indeed included in 
LICENSE.txt, but is not explicitly linked to a specific dependency. (FWIW the 
latest Cayenne core doesn't have any dependencies other than SLF4J; the Modeler 
and build tools have some). It was added way back before we migrated to Git 
(and truncated some of the history in the process). I suspect that whatever it 
was referring to is no longer around, but we may need to do some digging. 

Anyone else remembers what dependency EPL was covering?

Andrus



> On Jun 8, 2021, at 10:28 AM, Justin Mclean  wrote:
> 
> Hi,
> 
> I'm not part of your PMC, and there may be a reason(s) for this that I'm 
> unaware of, but I noticed a couple of unusual things in your release:
> 1. The LICENSE includes the Eclipse Public License. The EPL license is 
> Category B and in general you can't include anything that licensed Category B 
> in a source release. [1]
> 2. The source release includes compiled class files [2], and jar files 
> [3][4][5]. Compiled code shouldn't be included in a source release. The 
> gradle jar has been discussed many times and it can't be include in a source 
> release.
> 
> It would be great if you could take at look at these issues.
> 
> Kind Regards,
> Justin
> 
> 1. https://www.apache.org/legal/resolved.html#weak-copyleft-licenses
> 2. 
> ./cayenne-gradle-plugin/build/classes/java/main/org/apache/cayenne/tools/*.class
> 3. ./cayenne-gradle-plugin/gradle/wrapper/gradle-wrapper.jar
> 4. ./cayenne-gradle-plugin/build/libs/cayenne-gradle-plugin-4.2.M3.jar
> 5. ./cayenne-gradle-plugin/build/libs/cayenne-gradle-plugin-4.2.M3-sources.jar
> 6. ./cayenne-gradle-plugin/build/libs/cayenne-gradle-plugin-4.2.M3-javadoc.jar
> 
> 

[ANN] Cayenne 4.2.M3 released

[Andrus Adamchik]

I am glad to announce a release of Cayenne 4.2.M3. The release is stabilizing, 
so there are only a few new features. 

A notable one is support for annotated callback methods on entity classes 
(mapping those in the Modeler is annoying). Though we are still working out the 
performance aspects of it. So consider it "preview", and I'd advise to wait 
till the next release before going all in with annotations.

The most important part of the release is bug fixes though. I had a couple of 
personal blockers that prevented me from switching to 4.2 previously, such as 
incorrect SQL identifier quotation [1], MySQL 8 date time handling [2] (!! this 
may be a breaking change if you already used 4.2 with MySQL 8), precision of 
reverse-engineered dat/time types [3] and a few more. 

So I am looking forward to using M3 myself, and recommend an upgrade to all the 
current 4.2 users.

Andrus


[1] https://issues.apache.org/jira/browse/CAY-2686
[2] https://issues.apache.org/jira/browse/CAY-2691
[3] https://issues.apache.org/jira/browse/CAY-2694

Re: [VOTE] Apache Cayenne 4.2.M3 release

[Andrus Adamchik]

I can see the artifacts are already on Maven Central. I will work on the 
announcement.

Andrus


> On Mar 19, 2021, at 6:00 PM, Michael Gentry  wrote:
> 
> Awesome! Thanks Nikita!
> 
> 
> On Fri, Mar 19, 2021 at 10:21 AM Nikita Timofeev 
> wrote:
> 
>> With my +1 the result is following:
>> 
>> John Huss (PMC): +1
>> Andrus Adamchik (PMC): +1
>> Michael Gentry (PMC): +1
>> Nikita Timofeev (PMC): +1
>> 
>> I will finish the release today.
>> Thanks, everyone!
>> 
>> P.S. Here are issues that Michael have found:
>> https://issues.apache.org/jira/browse/CAY-2702 (callbacks menu, already
>> fixed)
>> https://issues.apache.org/jira/browse/CAY-2703 (tabs)
>> 
>> 
>> 
>> 
>> 
>> On Thu, Mar 18, 2021 at 3:07 PM Michael Gentry 
>> wrote:
>>> 
>>> * Checksums valid.
>>> * Signatures valid.
>>> * RAT valid.
>>> * DMG mounts.
>>> * Cayenne Modeller (only tested macOS version) runs [1,2].
>>> * Release builds [3].
>>> 
>>> +1 overall. I'd add a release/announcement note for the UI glitches.
>>> 
>>> Thanks!
>>> 
>>> mrg
>>> 
>>> 
>>> 1: There are a few UI glitches (https://imgur.com/a/ET6yWHb), at least
>> on
>>> macOS.
>>> 2: The Callbacks UI glitch appears to be a too-small column. You can
>> resize
>>> it and make it look better.
>>> 3: Java 8 and 11 build, Java 14 builds code-wise, but JavaDoc fails.
>>> 
>>> 
>>> On Sat, Mar 13, 2021 at 10:41 AM Nikita Timofeev <
>> ntimof...@objectstyle.com>
>>> wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> Here is hopefully the last milestone release of the 4.2.
>>>> 
>>>> Release notes:
>>>> https://github.com/apache/cayenne/blob/4.2.M3/RELEASE-NOTES.txt
>>>> Maven repo:
>>>> 
>> https://repository.apache.org/content/repositories/orgapachecayenne-1044/
>>>> Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.2.M3/
>>>> 
>>>> Please evaluate it and cast your votes.
>>>> 
>>>> --
>>>> Best regards,
>>>> Nikita Timofeev
>>>> 
>> 
>> 
>> 
>> --
>> Best regards,
>> Nikita Timofeev
>> 

Re: [VOTE] Apache Cayenne 4.2.M3 release

[Andrus Adamchik]

I suppose the important scenario is the lowest JDK version (i.e. 8), as it 
produces forward-compatible binaries.

Andrus


> On Mar 18, 2021, at 2:43 PM, Michael Gentry  wrote:
> 
> What are the expected build scenarios? With Java 8 and 11, everything built
> successfully. With Java 14, it errors out at the documentation:
> 
> [INFO] tutorial-rop-server-http2: Cayenne ROP HTTP/2 Server Tutorial
> SUCCESS [  0.297 s]
> [INFO] cayenne-docs-parent: Cayenne Documentation Parent .. SUCCESS [
> 0.017 s]
> [INFO] cayenne-doc: Cayenne Documentation . FAILURE [
> 9.469 s]
> [INFO] cayenne-asciidoc: Cayenne AsciiDoc Documentation parent SKIPPED
> [INFO] cayenne-asciidoc-extension . SKIPPED
> [INFO] cayenne-guide: AsciiDoc - Cayenne Framework Guide .. SKIPPED
> [INFO] getting-started-guide: AsciiDoc - Getting Started with Cayenne
> SKIPPED
> [INFO] getting-started-db-first: AsciiDoc - Cayenne Database First tutorial
> SKIPPED
> [INFO] getting-started-rop: AsciiDoc - Getting Started with Cayenne ROP
> (Remote Object Persistence) SKIPPED
> [INFO] upgrade-guide: Asciidoc - Cayenne New Features and Upgrade Guide
> SKIPPED
> [INFO] cayenne-assembly: Cayenne Release Assembly . SKIPPED
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time:  03:01 min
> [INFO] Finished at: 2021-03-18T07:38:57-04:00
> [INFO]
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.1.1:javadoc (javadoc) on
> project cayenne-doc: An error has occurred in Javadoc report generation:
> [ERROR] Exit code: 1 - javadoc: error - invalid flag:
> --no-module-directories
> [ERROR]
> [ERROR] Command line was: /Users/mrg/.jenv/versions/14/bin/javadoc @options
> @argfile
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/Users/mrg/Projects/Cayenne-Release/cayenne-4.2.M3-src/docs/doc/target/site/apidocs/doc/api'
> dir.
> 
> 
> 
> On Sat, Mar 13, 2021 at 10:41 AM Nikita Timofeev 
> wrote:
> 
>> Hi all,
>> 
>> Here is hopefully the last milestone release of the 4.2.
>> 
>> Release notes:
>> https://github.com/apache/cayenne/blob/4.2.M3/RELEASE-NOTES.txt
>> Maven repo:
>> https://repository.apache.org/content/repositories/orgapachecayenne-1044/
>> Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.2.M3/
>> 
>> Please evaluate it and cast your votes.
>> 
>> --
>> Best regards,
>> Nikita Timofeev
>> 

Re: [VOTE] Apache Cayenne 4.2.M3 release

[Andrus Adamchik]

Hi Mike,

Looks like the list strips off the attachments.

Andrus

> On Mar 18, 2021, at 6:31 AM, Michael Gentry  wrote:
> 
> Also the ObjEntity Callbacks tab view:
> 
> 
> 
> 
> On Thu, Mar 18, 2021 at 6:29 AM Michael Gentry  <mailto:blackn...@gmail.com>> wrote:
> Are the tabs in CM on macOS supposed to look this way?
> 
> 
> 
> 
> On Wed, Mar 17, 2021 at 2:57 AM Andrus Adamchik  <mailto:and...@objectstyle.org>> wrote:
> +1
> 
> Lots of fixes that address problems throughout my apps and downstream 
> frameworks. E.g. I was able to remove a bunch of hacks from Agrest with this 
> upgrade. Great job!
> 
> Andrus 
> 
> 
> > On Mar 13, 2021, at 6:41 PM, Nikita Timofeev  > <mailto:ntimof...@objectstyle.com>> wrote:
> > 
> > Hi all,
> > 
> > Here is hopefully the last milestone release of the 4.2.
> > 
> > Release notes: 
> > https://github.com/apache/cayenne/blob/4.2.M3/RELEASE-NOTES.txt 
> > <https://github.com/apache/cayenne/blob/4.2.M3/RELEASE-NOTES.txt>
> > Maven repo: 
> > https://repository.apache.org/content/repositories/orgapachecayenne-1044/ 
> > <https://repository.apache.org/content/repositories/orgapachecayenne-1044/>
> > Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.2.M3/ 
> > <https://dist.apache.org/repos/dist/dev/cayenne/4.2.M3/>
> > 
> > Please evaluate it and cast your votes.
> > 
> > -- 
> > Best regards,
> > Nikita Timofeev
> 

[ANN] Cayenne 4.2.M2 release

[Andrus Adamchik]

4.2.M2 release is out [1]. A few cool things in this release:

* Support for JSON and geospatial value types.
* Ordering on aggregate functions and in-memory evaluation of aggregate 
expressions.
* Modeler support for downloading JDBC drivers from maven central.
* Runtime changes that may be less obvious to the end user, but allow to handle 
a variety of edge cases.
* Bug fixes

Also looks like we are pretty close to beta freeze. The main scope of 4.2 is 
done, though of course improvement ideas keep popping up all the time, 
especially now that the new stack significantly expanded our SQL vocabulary and 
JDBC capabilities. E.g. one such idea is using EXISTS instead of JOIN + 
DISTINCT for to-many conditions [2].

Enjoy M2!

Andrus

[1] https://cayenne.apache.org/2020/10/cayenne-42m2-released/
[2] https://issues.apache.org/jira/browse/CAY-2684

Re: [VOTE] Apache Cayenne 4.2.M2 release

[Andrus Adamchik]

All good. +1


> On Oct 6, 2020, at 9:33 PM, Nikita Timofeev  wrote:
> 
> Hi all,
> 
> Here is another milestone release of the 4.2.
> There are not as many changes in this build as in the first milestone,
> but I think it's time to move 4.2 further.
> 
> Release notes: https://github.com/apache/cayenne/blob/4.2.M2/RELEASE-NOTES.txt
> Maven repo: 
> https://repository.apache.org/content/repositories/orgapachecayenne-1042/
> Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.2.M2/
> 
> Please evaluate it and cast your votes.
> 
> -- 
> Best regards,
> Nikita Timofeev

[ANN] Cayenne 4.1 goes final

[Andrus Adamchik]

Very excited to announce the final / GA release of Apache Cayenne 4.1! It is 
available on Maven central and as a download on cayenne.apache.org.

For the 4.0 users this is an exciting upgrade, offering an immediate and 
tangible performance boost (field-based data objects) and a new easy automated 
ORM workflow (modeler-based DB import). See this short video [1] for details. 
And here is a website announcement [2]. 

It's been "only" 2 years since 4.0 went final. Our GA cycles are shortening, 
and will hopefully shorten even further with 4.2.

Thanks to everyone who made it happen - developers, users, testers. We have an 
amazing community that sustained this project over the years! Looking forward 
to the new things that are happening in 4.2, and the plans beyond that.

Andrus


[1] https://www.youtube.com/watch?v=GW3l7bAJgKg
[2] https://cayenne.apache.org/2020/07/cayenne-41-final-released/
[3] Bug fixes since 4.1.RC2:

CAY-2642 EhCache memory leak due to misconfiguration
CAY-2643 ObjectSelect.prefetch(name, semantics) method creates a phantom node
CAY-2646 Wrong target path selection logic in cgen config
CAY-2647 Modeler: project upgrade from 4.0.B2 to 4.1.RC2 failure
CAY-2653 No methods for queries with qualifier parameters generated
CAY-2654 Exception in dbimport when relationships should be imported, but no 
explicit configuration exists

Re: [VOTE] Apache Cayenne 4.1 release

[Andrus Adamchik]

Thanks all. 

I was going to write an announcement in a few days. Also working on a simple 
"What's new" video.

Andrus 


> On Jul 21, 2020, at 1:08 PM, Nikita Timofeev  
> wrote:
> 
> Here is my
> +1
> 
> And here is the results:
> 
> John Huss (PMC): +1
> Andrus Adamchik (PMC): +1
> Aristedes Maniatis (PMC): +1
> Nikita Timofeev (PMC): +1
> 
> I will finish the release today.
> Thanks, everyone!
> 
> On Mon, Jul 20, 2020 at 11:34 AM Aristedes Maniatis
>  wrote:
>> 
>> +1
>> 
>> My review was on OSX. We have that annoying security alert for Modeler
>> which I believe is almost unsolvable for open source projects. I've a
>> bit of experience with Apple's codesigning and it is a nightmare. Even
>> when you get it working, it breaks until you log into their portal every
>> month or two and accept new terms and conditions.
>> 
>> Other that that nonsense everything is looking good. Actually not good,
>> brilliant! The documentation is looking better every time I take a look
>> at it and the upgrade notes are great.
>> 
>> 
>> For a laugh I added Cayenne to OSX homebrew. I added 4.0.2, but will
>> upgrade that to 4.1 once this is ready.
>> 
>> 
>> Nikita and everyone else here... very well done indeed. I've had 4.1
>> milestones in a commercial project for what feels like years now.
>> 
>> Ari
>> 
>> 
>> 
>> On 15/7/20 1:57am, Nikita Timofeev wrote:
>>> Hi all,
>>> 
>>> The GA release of Cayenne 4.1 is almost here!
>>> 
>>> Release notes: https://github.com/apache/cayenne/blob/4.1/RELEASE-NOTES.txt
>>> Maven repo: 
>>> https://repository.apache.org/content/repositories/orgapachecayenne-1040/
>>> Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.1/
>>> 
>>> Please evaluate and cast your votes.
>>> 
> 
> 
> 
> -- 
> Best regards,
> Nikita Timofeev

Re: [VOTE] Apache Cayenne 4.1 release

[Andrus Adamchik]

+1


Noticed a few minor things that do not affect my vote.

* Copyright year in the Modeler is still 2019
* A snapshot version of Rat that I am using 
(apache-rat-0.14-20200227.222331-84.jar) complains about our exclude patterns, 
and consequently reports all these excluded files as unlicensed (did they 
switch from globs to regex?)

Will skip given exclusion '*.plist' due to 
java.util.regex.PatternSyntaxException: Dangling meta character '*' near index 0
*.plist
^
Will skip given exclusion '*.fspec' due to 
java.util.regex.PatternSyntaxException: Dangling meta character '*' near index 0
*.fspec
^
Will skip given exclusion '*.map.xml' due to 
java.util.regex.PatternSyntaxException: Dangling meta character '*' near index 0
*.map.xml
^
Will skip given exclusion '*.graph.xml' due to 
java.util.regex.PatternSyntaxException: Dangling meta character '*' near index 0
*.graph.xml
^
Will skip given exclusion '*.driver.xml' due to 
java.util.regex.PatternSyntaxException: Dangling meta character '*' near index 0
*.driver.xml
^
Will skip given exclusion '*.html' due to 
java.util.regex.PatternSyntaxException: Dangling meta character '*' near index 0
*.html
^
Will skip given exclusion '*.css' due to 
java.util.regex.PatternSyntaxException: Dangling meta character '*' near index 0
*.css
^
Will skip given exclusion '*.jceks' due to 
java.util.regex.PatternSyntaxException: Dangling meta character '*' near index 0
*.jceks
^
Will skip given exclusion '*.iml' due to 
java.util.regex.PatternSyntaxException: Dangling meta character '*' near index 0
*.iml
^
 
Andrus


> On Jul 14, 2020, at 6:57 PM, Nikita Timofeev  
> wrote:
> 
> Hi all,
> 
> The GA release of Cayenne 4.1 is almost here!
> 
> Release notes: https://github.com/apache/cayenne/blob/4.1/RELEASE-NOTES.txt
> Maven repo: 
> https://repository.apache.org/content/repositories/orgapachecayenne-1040/
> Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.1/
> 
> Please evaluate and cast your votes.
> 
> -- 
> Best regards,
> Nikita Timofeev

Re: Comparing BigDecimals

[Andrus Adamchik]

It should not. "instanceof" takes care of weeding out nulls.


> On Jun 9, 2020, at 3:11 PM, Michael Gentry  wrote:
> 
> BTW, I believe your current implementation will NPE on a null o2 here:
> 
> return ((BigDecimal) o1).compareTo((BigDecimal) o2) == 0;
> 
> 
> 
> On Fri, Jun 5, 2020 at 11:34 AM Michael Gentry  wrote:
> 
>> Will adding this work?  (Worked in a simple test I wrote.)
>> 
>>public static boolean nullSafeEquals(BigDecimal o1, BigDecimal o2)
>>{
>>if (o1 == null || o2 == null)
>>return o1 == o2;
>> 
>>return o1.compareTo(o2) == 0;
>>}
>> 
>> Then delete the BigDecimal stuff from the other nullSafeEquals.  (Revert
>> the changes.)
>> 
>> 
>> 
>> On Fri, Jun 5, 2020 at 8:47 AM Andrus Adamchik 
>> wrote:
>> 
>>> Hi folks,
>>> 
>>> Just ran into an obscure and minor but at the same time fundamental bug -
>>> Cayenne generated unneeded updates when the only change is BidDecimal value
>>> scale [1]. Essentially for BigDecimals we shouldn't be calling
>>> "a.equals(b)" but use "a.compareTo(b) == 0". I have a fix [2], but using
>>> "instanceof" inside a common performance-sensitive code feels dirty. I'd
>>> much rather a comparison strategy to be a part of the PropertyDescriptor
>>> object or something. So not applying the PR just yet.
>>> 
>>> Wanted to mention it here. Perhaps there are other data types that can't
>>> use "equals" for some reason. And perhaps there are other solutions to this
>>> problem too...
>>> 
>>> Andrus
>>> 
>>> [1] https://issues.apache.org/jira/browse/CAY-2660
>>> [2] https://github.com/apache/cayenne/pull/426
>> 
>> 

Comparing BigDecimals

[Andrus Adamchik]

Hi folks,

Just ran into an obscure and minor but at the same time fundamental bug - 
Cayenne generated unneeded updates when the only change is BidDecimal value 
scale [1]. Essentially for BigDecimals we shouldn't be calling "a.equals(b)" 
but use "a.compareTo(b) == 0". I have a fix [2], but using "instanceof" inside 
a common performance-sensitive code feels dirty. I'd much rather a comparison 
strategy to be a part of the PropertyDescriptor object or something. So not 
applying the PR just yet.

Wanted to mention it here. Perhaps there are other data types that can't use 
"equals" for some reason. And perhaps there are other solutions to this problem 
too...

Andrus

[1] https://issues.apache.org/jira/browse/CAY-2660
[2] https://github.com/apache/cayenne/pull/426

Re: Cayenne geospatial features

[Andrus Adamchik]

I finally got some time to play with Cayenne 4.2 and PostGIS [1]. I implemented 
something similar to Tore's WKTGeometryType, using 
"org.locationtech.jts:jts-core" lib for geometries. Though it required an extra 
step: byte[] coming back on select would not convert to Geometry properly. So I 
had to wrap select column in a PostGIS "ST_AsBinary" function. Luckily Cayenne 
4.2 makes it possible, and actually quite easy, as there is a full AST for the 
generated SQL that can be manipulated [2]. Thanks Nikita, this API is awesome! 
:) 

This is just a POC, and I can think of a few more improvements. E.g.:

* Lazy geometry parsing
* Support for other geometry representations, such as GeoJSON 
("org.wololo:jts2geojson"), that will require other column functions .
* Provide a set of custom functions for expressions.
* ... 

I am not yet sure as to the final home of this module. Initially I was planning 
to use it on a commercial project. But I'd certainly want to distill it to a 
reusable open source library.

Andrus

[1] https://github.com/andrus/cayenne-postgis 
<https://github.com/andrus/cayenne-postgis>
[2] 
https://github.com/andrus/cayenne-postgis/blob/master/src/main/java/org/example/cayenne/postgis/cayenne/PostgisSQLTreeProcessor.java



> On Feb 25, 2019, at 10:17 AM, Nikita Timofeev  
> wrote:
> 
> Hi Andrus,
> 
>> 
>> 1. Custom functions (already on master - [1])
>> 2. Joins that are not equi-joins (spatial joins [2] in our case - 
>> ST_Intersects/ST_Contains/etc).
>> 
>> @Nikita - anything else I might have missed?
> 
> Essentially that's it for now. Here are links to related JIRA tasks:
> 
> https://issues.apache.org/jira/browse/CAY-2512
> https://issues.apache.org/jira/browse/CAY-2526
> https://issues.apache.org/jira/browse/CAY-2529
> https://issues.apache.org/jira/browse/CAY-2528
> 
> On Sat, Feb 23, 2019 at 5:38 PM Andrus Adamchik  
> wrote:
>> 
>> Hi Tore,
>> 
>> Thanks for sharing your solutions.
>> 
>>> Next up is PostGIS queries. PostGIS queries are very powerful, but the 
>>> syntax can be quite strange. SQLTemplate or something similar should work 
>>> fine. I have some simple application specific java abstraction to the most 
>>> common stuff like ST_Intersects to fetch rows matching a tile and such.
>> 
>> This is primarily the area where we think we might improve Cayenne 
>> abstractions for both spatial and non-spatial advanced SQL. We'd like to add 
>> the ability for object queries / mapping to contain the following:
>> 
>> 1. Custom functions (already on master - [1])
>> 2. Joins that are not equi-joins (spatial joins [2] in our case - 
>> ST_Intersects/ST_Contains/etc).
>> 
>> @Nikita - anything else I might have missed?
>> 
>> None of the above appears to break the basic ORM assumptions, just taking 
>> them to the next level. So hopefully it won't create leaky abstractions.
>> 
>> Andrus
>> 
>> [1] https://issues.apache.org/jira/browse/CAY-2512
>> [2] http://postgis.net/workshops/postgis-intro/joins.html
>> 
>> 
>> 
>> 
>>> On Feb 23, 2019, at 1:40 AM, Tore Halset  wrote:
>>> 
>>> Hello.
>>> 
>>> With Cayenne, you can easily create a ExtendedType that convert JTS 
>>> geometries on the java side to Well-Known Binary on the database side. I 
>>> did create a similar ExtendedType to create JTS geometries to Well-Known 
>>> Text for storing JTS geometries as text (se below). We have used this in 
>>> production for several years. For PostGIS, I have not used Cayenne on the 
>>> geometries, but it should work identical.
>>> 
>>> A long time ago, I wrote about this over at 
>>> http://objectstyle.org/confluence/display/CAY/Mapping+JTS+Geometries , but 
>>> that website does not exist anymore.
>>> 
>>> Next up is PostGIS queries. PostGIS queries are very powerful, but the 
>>> syntax can be quite strange. SQLTemplate or something similar should work 
>>> fine. I have some simple application specific java abstraction to the most 
>>> common stuff like ST_Intersects to fetch rows matching a tile and such.
>>> 
>>> For related libraries, JTS has lots of geometry goodies. It is in the 
>>> middle of a move with package name switch. The old one from vividsolutions 
>>> is most compatible with other libraries for now. Geotools has lots of 
>>> goodies for projection and such. And perhaps our library, 
>>> https://github.com/ElectronicChartCentre/java-vector-tile , for 
>>> constructing Mapbox Vector Tiles from java for use in Mapbox GL JS 

Re: That warning when combining a joint prefetch with a fetch limit

[Andrus Adamchik]

Hi Hugi,

I think you are right in general. But I can't seem to find the warning you are 
referring to. What is the exact text, so I can search for it in the code?

Andrus

> On May 16, 2020, at 11:23 AM, Hugi Thordarson  wrote:
> 
> Hi all,
> just wondering; the warning that's logged if a query uses a joint prefetch in 
> conjunction with a limit—shouldn't that only apply to to-many relationships?
> 
> Cheers,
> - hugi

4.2 - DISTINCT in column query

[Andrus Adamchik]

TL;DR: Cayenne using DISTINCT for column queries in 4.2 affects Agrest 
algorithms, but is nevertheless correct and should stay around.


When testing M1, I noticed a difference in ordering of the second-level results 
in Agrest vs 4.0/4.1. Those are generated in Agrest via a SelectQuery with 
columns roughly looking like this:

  List> properties = new ArrayList<>();
  properties.add(Property.createSelf(E3.class));

  Expression exp = ExpressionFactory.dbPathExp("e2.id");
  properties.add(Property.create(exp, Integer.class));

  SelectQuery query = new SelectQuery(E3.class);
  query.setColumns(properties);

Here "e2" is a to-one relationship. The difference in generated SQL between 4.0 
and 4.2 is the DISTINCT keyword added in the latter:

4.0: 
  SELECT t0.name, t0.e2_id, t0.id_, t1.id_ FROM utest.e3 t0 JOIN utest.e2 t1 ON 
(t0.e2_id = t1.id_)

4.2:
  SELECT DISTINCT t0.name, t0.e2_id, t0.id_, t1.id_ FROM utest.e3 t0 JOIN 
utest.e2 t1 ON t0.e2_id = t1.id_ 

Both produce the correct result, but since there's no explicit ordering, the 
actual order of the objects returned by Derby is different. I am less worried 
about the ordering (this was just an indicator to me that something has 
changed), but DISTINCT has a performance impact, and now it seems it will 
affect the main execution path of Agrest. 

I suppose Cayenne behavior in 4.2 is correct as with column queries there are 
no simple rules for when there may be duplicate result rows. Our case doesn't 
require DISTINCT only because of the special combination (entity and a related 
to-one id). And we need to fix this on Agrest end (that join is redundant in 
case of to-one). 

Still figured I'd mention...

Andrus

Re: [VOTE] Apache Cayenne 4.2.M1 release

[Andrus Adamchik]

+1

> On Apr 15, 2020, at 3:55 PM, Nikita Timofeev  
> wrote:
> 
> Hi all,
> 
> I hope this will be the last try for the 4.2.M1.
> 
> Release notes: https://github.com/apache/cayenne/blob/4.2.M1/RELEASE-NOTES.txt
> Maven repo: 
> https://repository.apache.org/content/repositories/orgapachecayenne-1039/
> Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.2.M1/
> 
> Please evaluate and cast your votes.
> 
> -- 
> Best regards,
> Nikita Timofeev

Re: [VOTE] Apache Cayenne 4.2.M1 release

[Andrus Adamchik]

> @Andrus: We'll let you test LM first this time?

Be happy to.


> On Apr 14, 2020, at 7:48 PM, Michael Gentry  wrote:
> 
> @John & @Nikita: If easy to fix, let's go ahead and do it just to have a
> better M1.
> @Andrus: We'll let you test LM first this time?
> 
> I guess that makes me more of a -0 now.  I'm still not opposed to releasing
> as-is, but a better M1 is still desirable.
> 
> 
> On Tue, Apr 14, 2020 at 5:10 AM Nikita Timofeev 
> wrote:
> 
>> That's not a big effort to prepare a fresh release, it getting faster
>> each time :).
>> So I think I could do it one more time.
>> 
>> As for the issue, the fix seems straightforward, so I'll just go for it.
>> 
>> On Tue, Apr 14, 2020 at 4:30 AM John Huss  wrote:
>>> 
>>> I would be fine with fixing it up and remaking the release, but I don’t
>>> know how much of a hassle that is. I can find time to fix AutoAdapter in
>>> the next two days I think.
>>> 
>>> On Mon, Apr 13, 2020 at 1:34 PM Andrus Adamchik 
>>> wrote:
>>> 
>>>> Been thinking more about this... This breaks basic commit operations
>> for
>>>> both Derby and SQLServer, making it a major issue. We've never shipped
>>>> releases with known bugs like this, even milestones. On the other hand
>>>> there is a workaround - use an explicit adapter.
>>>> 
>>>> I am voting -0, which means that I wouldn't release it like that, but I
>>>> don't want to veto the release either. If the majority decides we
>> should
>>>> proceed, so be it.
>>>> 
>>>> Andrus
>>>> 
>>>> 
>>>>> On Apr 13, 2020, at 2:53 PM, Michael Gentry 
>> wrote:
>>>>> 
>>>>> Hi Andrus,
>>>>> 
>>>>> Given this is a milestone release, I think it is fine to release
>> with the
>>>>> AutoAdapter issue.  These releases aren't required or expected to be
>>>>> production-ready, although that would certainly be nice.  They are
>> for
>>>>> finding issues needing to be addressed, and you have.  :-)
>>>>> 
>>>>> mrg
>>>>> 
>>>>> 
>>>>> On Mon, Apr 13, 2020 at 5:24 AM Andrus Adamchik <
>> and...@objectstyle.org>
>>>>> wrote:
>>>>> 
>>>>>> So looks like this will affect users of Derby and SQLServer who are
>> also
>>>>>> using the AutoAdapter (don't know if anyone still NOT using the
>>>>>> AutoAdapter?). I suppose we can still release the M1, though it will
>>>> not be
>>>>>> usable for me unfortunately until this is fixed.
>>>>>> 
>>>>>> Thoughts?
>>>>>> 
>>>>>> Andrus
>>>>>> 
>>>>>>> On Apr 13, 2020, at 11:40 AM, Nikita Timofeev <
>>>> ntimof...@objectstyle.com>
>>>>>> wrote:
>>>>>>> 
>>>>>>> Hi Andrus,
>>>>>>> 
>>>>>>> Yes, LinkMove problems related to batch generated keys. The
>> problem is
>>>>>>> with AutoAdapter, it simply doesn't define
>>>>>>> supportsGeneratedKeysForBatchInserts() method.
>>>>>>> DerbyAdapter itself works fine.
>>>>>>> 
>>>>>>> On Sun, Apr 12, 2020 at 11:47 AM Andrus Adamchik <
>>>> and...@objectstyle.org>
>>>>>> wrote:
>>>>>>>> 
>>>>>>>> Still testing the release... As expected 4.2 is no longer a
>> drop-in
>>>>>> replacement of 4.0 for either Agrest or LinkMove (because of the
>>>> Property
>>>>>> class refactoring). So I made a few tweaks to LM to make it compile
>> [1].
>>>>>> Now I am getting the following error on commit in a bunch of tests
>> (e.g.
>>>>>> CreateIT) [2].
>>>>>>>> 
>>>>>>>> Is this related to 57332e865f5dabb9c7adef4bac9a61137f6828c4 (batch
>>>> mode
>>>>>> and PKs on Derby) ?
>>>>>>>> 
>>>>>>>> (Derby version used in tests is 10.14.2.0 - the latest that
>> supports
>>>>>> Java 8)
>>>>>>>> 
>>>>>>>> Andrus
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Apr 7, 2020, at 2:03 PM, 

Re: [VOTE] Apache Cayenne 4.2.M1 release

[Andrus Adamchik]

Been thinking more about this... This breaks basic commit operations for both 
Derby and SQLServer, making it a major issue. We've never shipped releases with 
known bugs like this, even milestones. On the other hand there is a workaround 
- use an explicit adapter.

I am voting -0, which means that I wouldn't release it like that, but I don't 
want to veto the release either. If the majority decides we should proceed, so 
be it.

Andrus


> On Apr 13, 2020, at 2:53 PM, Michael Gentry  wrote:
> 
> Hi Andrus,
> 
> Given this is a milestone release, I think it is fine to release with the
> AutoAdapter issue.  These releases aren't required or expected to be
> production-ready, although that would certainly be nice.  They are for
> finding issues needing to be addressed, and you have.  :-)
> 
> mrg
> 
> 
> On Mon, Apr 13, 2020 at 5:24 AM Andrus Adamchik 
> wrote:
> 
>> So looks like this will affect users of Derby and SQLServer who are also
>> using the AutoAdapter (don't know if anyone still NOT using the
>> AutoAdapter?). I suppose we can still release the M1, though it will not be
>> usable for me unfortunately until this is fixed.
>> 
>> Thoughts?
>> 
>> Andrus
>> 
>>> On Apr 13, 2020, at 11:40 AM, Nikita Timofeev 
>> wrote:
>>> 
>>> Hi Andrus,
>>> 
>>> Yes, LinkMove problems related to batch generated keys. The problem is
>>> with AutoAdapter, it simply doesn't define
>>> supportsGeneratedKeysForBatchInserts() method.
>>> DerbyAdapter itself works fine.
>>> 
>>> On Sun, Apr 12, 2020 at 11:47 AM Andrus Adamchik 
>> wrote:
>>>> 
>>>> Still testing the release... As expected 4.2 is no longer a drop-in
>> replacement of 4.0 for either Agrest or LinkMove (because of the Property
>> class refactoring). So I made a few tweaks to LM to make it compile [1].
>> Now I am getting the following error on commit in a bunch of tests (e.g.
>> CreateIT) [2].
>>>> 
>>>> Is this related to 57332e865f5dabb9c7adef4bac9a61137f6828c4 (batch mode
>> and PKs on Derby) ?
>>>> 
>>>> (Derby version used in tests is 10.14.2.0 - the latest that supports
>> Java 8)
>>>> 
>>>> Andrus
>>>> 
>>>> 
>>>>> On Apr 7, 2020, at 2:03 PM, Nikita Timofeev 
>> wrote:
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>> Here is another try for the Cayenne 4.2.M1 release.
>>>>> 
>>>>> Release notes:
>> https://github.com/apache/cayenne/blob/4.2.M1/RELEASE-NOTES.txt
>>>>> Maven repo:
>> https://repository.apache.org/content/repositories/orgapachecayenne-1038/
>>>>> Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.2.M1/
>>>>> 
>>>>> Please evaluate and cast your votes.
>>>>> 
>>>>> --
>>>>> Best regards,
>>>>> Nikita Timofeev
>>>> 
>>>> 
>>>> [1] https://github.com/nhl/link-move/tree/cayenne-4.2 <
>> https://github.com/nhl/link-move/tree/cayenne-4.2>
>>>> 
>>>> [2]  org.apache.cayenne.CayenneRuntimeException: [v.4.2.M1 Apr 07 2020
>> 09:32:02] Mismatching number of generated PKs: expected 2, instead got 1
>>>> at
>> org.apache.cayenne.access.flush.FlushObserver.nextGeneratedRows(FlushObserver.java:77)
>>>> at
>> org.apache.cayenne.access.DataNodeQueryAction$1.nextGeneratedRows(DataNodeQueryAction.java:77)
>>>> at
>> org.apache.cayenne.access.jdbc.BatchAction.processGeneratedKeys(BatchAction.java:288)
>>>> at
>> org.apache.cayenne.access.jdbc.BatchAction.runAsBatch(BatchAction.java:133)
>>>> at
>> org.apache.cayenne.access.jdbc.BatchAction.performAction(BatchAction.java:94)
>>>> at
>> org.apache.cayenne.access.DataNodeQueryAction.runQuery(DataNodeQueryAction.java:97)
>>>> at org.apache.cayenne.access.DataNode.performQueries(DataNode.java:273)
>>>> at
>> org.apache.cayenne.access.flush.DefaultDataDomainFlushAction.lambda$executeQueries$6(DefaultDataDomainFlushAction.java:175)
>>>> at java.util.HashMap.forEach(HashMap.java:1288)
>>>> at
>> org.apache.cayenne.access.flush.DefaultDataDomainFlushAction.executeQueries(DefaultDataDomainFlushAction.java:174)
>>>> at
>> org.apache.cayenne.access.flush.DefaultDataDomainFlushAction.flush(DefaultDataDomainFlushAction.java:89)
>>>> at org.apache.cayenne.access.DataDomain.onSyncFlush(DataDomain.java:637)
>>>> at
>> org.apache.

Re: [VOTE] Apache Cayenne 4.2.M1 release

[Andrus Adamchik]

So looks like this will affect users of Derby and SQLServer who are also using 
the AutoAdapter (don't know if anyone still NOT using the AutoAdapter?). I 
suppose we can still release the M1, though it will not be usable for me 
unfortunately until this is fixed.

Thoughts?

Andrus 

> On Apr 13, 2020, at 11:40 AM, Nikita Timofeev  
> wrote:
> 
> Hi Andrus,
> 
> Yes, LinkMove problems related to batch generated keys. The problem is
> with AutoAdapter, it simply doesn't define
> supportsGeneratedKeysForBatchInserts() method.
> DerbyAdapter itself works fine.
> 
> On Sun, Apr 12, 2020 at 11:47 AM Andrus Adamchik  
> wrote:
>> 
>> Still testing the release... As expected 4.2 is no longer a drop-in 
>> replacement of 4.0 for either Agrest or LinkMove (because of the Property 
>> class refactoring). So I made a few tweaks to LM to make it compile [1]. Now 
>> I am getting the following error on commit in a bunch of tests (e.g. 
>> CreateIT) [2].
>> 
>> Is this related to 57332e865f5dabb9c7adef4bac9a61137f6828c4 (batch mode and 
>> PKs on Derby) ?
>> 
>> (Derby version used in tests is 10.14.2.0 - the latest that supports Java 8)
>> 
>> Andrus
>> 
>> 
>>> On Apr 7, 2020, at 2:03 PM, Nikita Timofeev  
>>> wrote:
>>> 
>>> Hi all,
>>> 
>>> Here is another try for the Cayenne 4.2.M1 release.
>>> 
>>> Release notes: 
>>> https://github.com/apache/cayenne/blob/4.2.M1/RELEASE-NOTES.txt
>>> Maven repo: 
>>> https://repository.apache.org/content/repositories/orgapachecayenne-1038/
>>> Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.2.M1/
>>> 
>>> Please evaluate and cast your votes.
>>> 
>>> --
>>> Best regards,
>>> Nikita Timofeev
>> 
>> 
>> [1] https://github.com/nhl/link-move/tree/cayenne-4.2 
>> <https://github.com/nhl/link-move/tree/cayenne-4.2>
>> 
>> [2]  org.apache.cayenne.CayenneRuntimeException: [v.4.2.M1 Apr 07 2020 
>> 09:32:02] Mismatching number of generated PKs: expected 2, instead got 1
>> at 
>> org.apache.cayenne.access.flush.FlushObserver.nextGeneratedRows(FlushObserver.java:77)
>> at 
>> org.apache.cayenne.access.DataNodeQueryAction$1.nextGeneratedRows(DataNodeQueryAction.java:77)
>> at 
>> org.apache.cayenne.access.jdbc.BatchAction.processGeneratedKeys(BatchAction.java:288)
>> at 
>> org.apache.cayenne.access.jdbc.BatchAction.runAsBatch(BatchAction.java:133)
>> at 
>> org.apache.cayenne.access.jdbc.BatchAction.performAction(BatchAction.java:94)
>> at 
>> org.apache.cayenne.access.DataNodeQueryAction.runQuery(DataNodeQueryAction.java:97)
>> at org.apache.cayenne.access.DataNode.performQueries(DataNode.java:273)
>> at 
>> org.apache.cayenne.access.flush.DefaultDataDomainFlushAction.lambda$executeQueries$6(DefaultDataDomainFlushAction.java:175)
>> at java.util.HashMap.forEach(HashMap.java:1288)
>> at 
>> org.apache.cayenne.access.flush.DefaultDataDomainFlushAction.executeQueries(DefaultDataDomainFlushAction.java:174)
>> at 
>> org.apache.cayenne.access.flush.DefaultDataDomainFlushAction.flush(DefaultDataDomainFlushAction.java:89)
>> at org.apache.cayenne.access.DataDomain.onSyncFlush(DataDomain.java:637)
>> at org.apache.cayenne.access.DataDomain.onSyncNoFilters(DataDomain.java:609)
>> at 
>> org.apache.cayenne.access.DataDomain$DataDomainSyncFilterChain.onSync(DataDomain.java:835)
>> at 
>> org.apache.cayenne.tx.TransactionFilter.lambda$onSync$0(TransactionFilter.java:61)
>> at 
>> org.apache.cayenne.tx.DefaultTransactionManager$BaseTransactionHandler.performInTransaction(DefaultTransactionManager.java:180)
>> at 
>> org.apache.cayenne.tx.DefaultTransactionManager$BaseTransactionHandler.performInNewTransaction(DefaultTransactionManager.java:152)
>> at 
>> org.apache.cayenne.tx.DefaultTransactionManager$NestedTransactionHandler.handle(DefaultTransactionManager.java:95)
>> at 
>> org.apache.cayenne.tx.DefaultTransactionManager.performInTransaction(DefaultTransactionManager.java:62)
>> at 
>> org.apache.cayenne.tx.DefaultTransactionManager.performInTransaction(DefaultTransactionManager.java:40)
>> at org.apache.cayenne.tx.TransactionFilter.onSync(TransactionFilter.java:61)
>> at 
>> org.apache.cayenne.access.DataDomain$DataDomainSyncFilterChain.onSync(DataDomain.java:834)
>> at org.apache.cayenne.access.DataDomain.onSync(DataDomain.java:596)
>> at org.apache.cayenne.access.DataContext.flushToParent(DataContext.java:737)
>> at org.apache.cayenne.access.DataContext.commitChanges(DataContext.java:686)
>> at 

Re: [VOTE] Apache Cayenne 4.2.M1 release

[Andrus Adamchik]

Still testing the release... As expected 4.2 is no longer a drop-in replacement 
of 4.0 for either Agrest or LinkMove (because of the Property class 
refactoring). So I made a few tweaks to LM to make it compile [1]. Now I am 
getting the following error on commit in a bunch of tests (e.g. CreateIT) [2].

Is this related to 57332e865f5dabb9c7adef4bac9a61137f6828c4 (batch mode and PKs 
on Derby) ?

(Derby version used in tests is 10.14.2.0 - the latest that supports Java 8)

Andrus


> On Apr 7, 2020, at 2:03 PM, Nikita Timofeev  wrote:
> 
> Hi all,
> 
> Here is another try for the Cayenne 4.2.M1 release.
> 
> Release notes: https://github.com/apache/cayenne/blob/4.2.M1/RELEASE-NOTES.txt
> Maven repo: 
> https://repository.apache.org/content/repositories/orgapachecayenne-1038/
> Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.2.M1/
> 
> Please evaluate and cast your votes.
> 
> -- 
> Best regards,
> Nikita Timofeev


[1] https://github.com/nhl/link-move/tree/cayenne-4.2 


[2]  org.apache.cayenne.CayenneRuntimeException: [v.4.2.M1 Apr 07 2020 
09:32:02] Mismatching number of generated PKs: expected 2, instead got 1
at 
org.apache.cayenne.access.flush.FlushObserver.nextGeneratedRows(FlushObserver.java:77)
at 
org.apache.cayenne.access.DataNodeQueryAction$1.nextGeneratedRows(DataNodeQueryAction.java:77)
at 
org.apache.cayenne.access.jdbc.BatchAction.processGeneratedKeys(BatchAction.java:288)
at org.apache.cayenne.access.jdbc.BatchAction.runAsBatch(BatchAction.java:133)
at org.apache.cayenne.access.jdbc.BatchAction.performAction(BatchAction.java:94)
at 
org.apache.cayenne.access.DataNodeQueryAction.runQuery(DataNodeQueryAction.java:97)
at org.apache.cayenne.access.DataNode.performQueries(DataNode.java:273)
at 
org.apache.cayenne.access.flush.DefaultDataDomainFlushAction.lambda$executeQueries$6(DefaultDataDomainFlushAction.java:175)
at java.util.HashMap.forEach(HashMap.java:1288)
at 
org.apache.cayenne.access.flush.DefaultDataDomainFlushAction.executeQueries(DefaultDataDomainFlushAction.java:174)
at 
org.apache.cayenne.access.flush.DefaultDataDomainFlushAction.flush(DefaultDataDomainFlushAction.java:89)
at org.apache.cayenne.access.DataDomain.onSyncFlush(DataDomain.java:637)
at org.apache.cayenne.access.DataDomain.onSyncNoFilters(DataDomain.java:609)
at 
org.apache.cayenne.access.DataDomain$DataDomainSyncFilterChain.onSync(DataDomain.java:835)
at 
org.apache.cayenne.tx.TransactionFilter.lambda$onSync$0(TransactionFilter.java:61)
at 
org.apache.cayenne.tx.DefaultTransactionManager$BaseTransactionHandler.performInTransaction(DefaultTransactionManager.java:180)
at 
org.apache.cayenne.tx.DefaultTransactionManager$BaseTransactionHandler.performInNewTransaction(DefaultTransactionManager.java:152)
at 
org.apache.cayenne.tx.DefaultTransactionManager$NestedTransactionHandler.handle(DefaultTransactionManager.java:95)
at 
org.apache.cayenne.tx.DefaultTransactionManager.performInTransaction(DefaultTransactionManager.java:62)
at 
org.apache.cayenne.tx.DefaultTransactionManager.performInTransaction(DefaultTransactionManager.java:40)
at org.apache.cayenne.tx.TransactionFilter.onSync(TransactionFilter.java:61)
at 
org.apache.cayenne.access.DataDomain$DataDomainSyncFilterChain.onSync(DataDomain.java:834)
at org.apache.cayenne.access.DataDomain.onSync(DataDomain.java:596)
at org.apache.cayenne.access.DataContext.flushToParent(DataContext.java:737)
at org.apache.cayenne.access.DataContext.commitChanges(DataContext.java:686)
at 
com.nhl.link.move.runtime.task.create.CreateSegmentProcessor.commitTarget(CreateSegmentProcessor.java:63)
at 
com.nhl.link.move.runtime.task.create.CreateSegmentProcessor.process(CreateSegmentProcessor.java:44)
at 
com.nhl.link.move.runtime.task.create.CreateTask.lambda$createBatchProcessor$1(CreateTask.java:72)
at com.nhl.link.move.batch.BatchRunner.run(BatchRunner.java:57)
at com.nhl.link.move.runtime.task.create.CreateTask.doRun(CreateTask.java:62)
at com.nhl.link.move.runtime.task.BaseTask.run(BaseTask.java:46)
at com.nhl.link.move.LmTask.run(LmTask.java:31)
at com.nhl.link.move.runtime.task.BaseTask.run(BaseTask.java:39)
at com.nhl.link.move.LmTask.run(LmTask.java:19)
at com.nhl.link.move.itest.CreateIT.testSync(CreateIT.java:24)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 

Re: [VOTE] Apache Cayenne 4.2.M1 release

[Andrus Adamchik]

> On Apr 7, 2020, at 9:28 PM, John Huss  wrote:
> 
> I got the rat 0.14 snapshot release, and everything looks good! Thanks!

Interesting. I tried building Rat 0.14 from their SVN trunk and got 
https-related errors. The binary SNAPSHOT from the repo works though. So I am 
all good too and will cast my vote as soon as I finish my checklist. Though 
figured I'd mention.

Andrus

Re: Cayenne callback listener in single transaction

[Andrus Adamchik]

Hi Artem,

> In fact I am interested in second scenario. 

> 
> 1. open transaction
> 2. perform main sql INSERT (db assign PK for new record)
> 3. perform callback operation (newly generated PK is accessible )
> 4. close transaction

Sure. Here is how to do it with CommitLogModule:

  ServerRuntime.builder()
  
.addModule(CommitLogModule.extend().addListener(MyCommitLogListener.class).module())

  public class MyCommitLogListener implements CommitLogListener {
  public void onPostCommit(ObjectContext originatingContext, ChangeMap 
changes) {
 // Here put the code for step #3. 
 // ChangeMap should have all the info on changed objects...
  }
  }


> On Dec 27, 2019, at 12:23 PM, Artem Kravchenko  
> wrote:
> 
> Hello Andrus
> Thanks for your replay.
> 
> Not sure how it works butfor example:
> I need to insert some Entity and on @PostPersist get the PK of this record.
> So the question is:
> 
> will 'insertBefore' collect all changes (main commit and callback) first and 
> then apply bulk SQL (inserts/updates)
> 
> or
> 
> 1. open transaction
> 2. perform main sql INSERT (db assign PK for new record)
> 3. perform callback operation (newly generated PK is accessible )
> 4. close transaction
> 
> In fact I am interested in second scenario
> first one doesn't fit for us
> 

Re: Watch out for memory leaks with EhCache

[Andrus Adamchik]

> On Dec 23, 2019, at 6:09 PM, John Huss  wrote:
> 
> I've decided to try using a simple QueryCache subclass I'm calling
> PartitionedQueryCache
>  which
> will enable independent lifetimes for the shared cache versus local cache.
> I'm going to run with this for a while. If there is any interest I can
> contribute it.
> 
> Thanks!

Ah right. There's another dimension to this discussion - separation of the 
long-living from short-living caches. This can also be achieved at the query 
level by using different cache groups. Each cache group maps to its own EhCache 
Cache object that has its own size and expiration settings.


> On Dec 23, 2019, at 6:09 PM, John Huss  wrote:
> 
>> 2. Set fairly short expiration times. E.g. 10x of your average response
>> time (say 10-30 sec).

BTW, the above statement from my previous email needs some clarification. When 
implementing "request-scope cache", you actually don't care if the expiration 
time is too long, as the cache is not shared between requests (if each request 
has its own ObjectContext). Eviction happens because of the *size* constraint, 
not expiration constraint.

So the conclusion here is that such a cache can be long-lived as well, just 
size-limited.

Andrus