Re: [VOTE] Apache Cayenne 4.2.M1 release

[Hugi]

Being somewhat absent these days I just wanted to thank you guys for your work. 
Feel free to laugh but I don’t think I’ve been this excited about a software 
upgrade since System 7. Doing a production upgrade for a non-essential but 
high-traffic app in the coming week.

Re: [VOTE] Apache Cayenne 4.2.M1 release

[Michael Gentry]

Thanks Nikita!


On Mon, Apr 20, 2020 at 3:53 AM Nikita Timofeev 
wrote:

> Here is my
> +1
>
> And here is the results:
>
> John Huss (PMC): +1
> Michael Gentry (PMC): +1
> Andrus Adamchik (PMC): +1
> Nikita Timofeev (PMC): +1
>
> Non-binding:
> Emerson Castañeda: +1
>
> I will finish the release today.
> Thanks, everyone!
>
>
> On Sat, Apr 18, 2020 at 10:56 AM Andrus Adamchik 
> wrote:
> >
> > +1
> >
> > > On Apr 15, 2020, at 3:55 PM, Nikita Timofeev <
> ntimof...@objectstyle.com> 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
> >
>
>
> --
> Best regards,
> Nikita Timofeev
>

Re: [VOTE] Apache Cayenne 4.2.M1 release

[Nikita Timofeev]

Here is my
+1

And here is the results:

John Huss (PMC): +1
Michael Gentry (PMC): +1
Andrus Adamchik (PMC): +1
Nikita Timofeev (PMC): +1

Non-binding:
Emerson Castañeda: +1

I will finish the release today.
Thanks, everyone!


On Sat, Apr 18, 2020 at 10:56 AM Andrus Adamchik  wrote:
>
> +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
>


--
Best regards,
Nikita Timofeev

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

[Emerson Castañeda]

Hi

+1 (non-binding)

1) Compiled from code
2) Ran  unit testing
3) RAT indicated no unlicensed files
4) Verified signatures
5) Verified SHA512
6) Ran compiled modeler / created and saved project

(java-11-openjdk-amd64)

Thanks

Emerson

On Thu, Apr 16, 2020 at 10:16 AM Michael Gentry  wrote:

> Hi Nikita!
>
> All of my release steps passed (assuming I use the RAT 0.14 snapshot) and
> building with Java 8 and Java 11 works.
>
> +1
>
> Thanks!
>
>
> On Wed, Apr 15, 2020 at 9:04 AM 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

[Michael Gentry]

Hi Nikita!

All of my release steps passed (assuming I use the RAT 0.14 snapshot) and
building with Java 8 and Java 11 works.

+1

Thanks!


On Wed, Apr 15, 2020 at 9:04 AM 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

[Nikita Timofeev]

I just checked LinkMove with the fixed version, everything seems good to me.
I'll start a new voting thread.

On Tue, Apr 14, 2020 at 7:57 PM Andrus Adamchik  wrote:
>
> > @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, Nikita Timofeev <
>  ntimof...@objectstyle.com>
> >> 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
> 

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, Nikita Timofeev <
 ntimof...@objectstyle.com>
>> 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
>> 
 
>> 

Re: [VOTE] Apache Cayenne 4.2.M1 release

[Michael Gentry]

@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, Nikita Timofeev <
> > > ntimof...@objectstyle.com>
> > > >> 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)
> > > 

Re: [VOTE] Apache Cayenne 4.2.M1 release

[Nikita Timofeev]

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 
> > > 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, Nikita Timofeev <
> > ntimof...@objectstyle.com>
> > >> 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
> > >>
> > 

Re: [VOTE] Apache Cayenne 4.2.M1 release

[John Huss]

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 
> > 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, Nikita Timofeev <
> ntimof...@objectstyle.com>
> >> 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
> >>
> 

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

Re: [VOTE] Apache Cayenne 4.2.M1 release

[Michael Gentry]

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

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 
>> 
>> 
>> [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)

Re: [VOTE] Apache Cayenne 4.2.M1 release

[Nikita Timofeev]

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 
> 
>
> [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 

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

[Emerson Castañeda]

Hi Nikita

WOW a lot of changes, new features, and bug fixes. Congrats

+1 (Non-binding)

My checks:

- Compiled from source, all tests  passed, and ran generated generic
modeler (java-8-openjdk-amd64 linux)
- RAT script executed - no unlicensed files
- Verified signature and hash for generic assembly and source code, and ran
modeler generic from assembly (java-8-openjdk-amd64 linux)

On Sat, Apr 11, 2020 at 9:01 AM Michael Gentry  wrote:

> Hi Nikita!
>
> All of my release steps passed and building with Java 8 and Java 11
> worked, including using Cayenne Modeler.
>
> +1
>
> Thanks!
>
>
> On Tue, Apr 7, 2020 at 7:03 AM 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
> >
>

Re: [VOTE] Apache Cayenne 4.2.M1 release

[Michael Gentry]

Hi Nikita!

All of my release steps passed and building with Java 8 and Java 11
worked, including using Cayenne Modeler.

+1

Thanks!


On Tue, Apr 7, 2020 at 7:03 AM 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
>

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: [VOTE] Apache Cayenne 4.2.M1 release

[John Huss]

+1

I got the rat 0.14 snapshot release, and everything looks good! Thanks!

1) verified signatures
2) verified archives are basically identical between platforms
3) RAT indicates no unlicensed files
4) compiled from source
5) unit tests ran successfully
6) macOS specific and Platform-agnostic modelers launch on macOS


On Tue, Apr 7, 2020 at 6:03 AM 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
>

Re: [VOTE] Apache Cayenne 4.2.M1 release

[John Huss]

Thanks, that issue appears to be fixed now!

On Fri, Apr 3, 2020 at 6:57 AM Nikita Timofeev 
wrote:

> Hi all,
>
> I've rolled back 4.2.M1 release and will start new voting soon.
> Fix for the meaningful FK is committed now [1].
> I've also checked that the latest snapshot version of the Apache RAT
> [2] is ok with the "https://;, so we could use it.
> I'll update docs and also will mention the maven plugin.
>
> John, could you please check again your meaningful FK test case with
> the latest cayenne snapshot build?
>
> [1] https://issues.apache.org/jira/browse/CAY-2652
> [2]
> https://repository.apache.org/content/repositories/snapshots/org/apache/rat/apache-rat/
>
> On Sat, Mar 28, 2020 at 1:04 AM John Huss  wrote:
> >
> > Thanks.
> >
> > I figured out the problem with cgen was that I had
> velocity-engine-core-2.0
> > instead of velocity-engine-core-2.1. Updating the jar fixed the problem.
> >
> >
> > On Thu, Mar 26, 2020 at 12:25 PM Nikita Timofeev <
> ntimof...@objectstyle.com>
> > wrote:
> >
> > > Thank you, John, for your thorough testing.
> > >
> > > 1. Seems like RAT don't like the change from "http://; to "https://;
> > > in the license text. I've updated settings for the RAT maven plugin
> > > (as I use it to check sources) and that works ok. Need to update
> > > config for the standalone script.
> > > 2. Cgen + ant. IIRC we had some problems with that and you helped a
> > > lot with it. I've tested cgen task in a simple demo project and it
> > > works fine for me, but I don't really know much about the Ant.
> > > If you can create a demo project or help somehow else, that would be
> great.
> > > 3. I was able to reproduce this one. Primitive type in the meaningful
> > > FK really creating problems, so need to fix this.
> > >
> > > I'll keep this vote open in case something else comes up.
> > >
> > > On Thu, Mar 26, 2020 at 1:05 AM John Huss  wrote:
> > > >
> > > > Thanks for all your work on this. 4.2 is going to be a great
> release! I
> > > ran
> > > > all my checks on the release and almost everything passed.
> > > >
> > > > I don't know what changed, but I'm having a RAT problem I haven't
> seen
> > > > before. RAT (both 0.12 and 0.13) show this header:
> > > >
> > > > Printing headers for text files without a valid license header...
> > > >
> > > >
> > > > then lists basically every source file in the archive, example below.
> > > When
> > > > I open this file directly the license header is there, but the
> printout
> > > > from RAT doesn't show it.
> > > >
> > > > =
> > > >
> > > > == File:
> > > >
> > >
> cayenne-4.2.M1-src/cayenne-osgi/src/test/java/org/apache/cayenne/configuration/osgi/OsgiClassLoaderManagerTest.java
> > > >
> > > > =
> > > >
> > > > /*
> > > >
> > > >  *
> > > >
> > > >  *
> > > >
> > > >  /
> > > >
> > > > package org.apache.cayenne.configuration.osgi;
> > > >
> > > >
> > > > import org.junit.Test;
> > > >
> > > >
> > > > import java.util.Collections;
> > > >
> > > >
> > > > import static org.junit.Assert.assertSame;
> > > >
> > > > import static org.mockito.Mockito.mock;
> > > >
> > > >
> > > > public class OsgiClassLoaderManagerTest {
> > > >
> > > >
> > > >
> > > >
> > >
> -
> > > > More importantly, I'm seeing some issues with cgen (using ant) not
> > > finding
> > > > templates. This wasn't happening when I tested 4.2 months ago, so it
> must
> > > > be a more recent change.
> > > >
> > > > org.apache.velocity.exception.ResourceNotFoundException: Unable to
> find
> > > > resource 'templates/v4_1/superclass.vm'
> > > >
> > > >
> > > > 
> > > >
> > > >  > > >
> > > > superpkg="com.myapp.auto"
> > > >
> > > > createpropertynames="true"
> > > >
> > > > destDir="src"
> > > >
> > > > outputPattern="*.java"
> > > >
> > > > usepkgpath="true"
> > > >
> > > > encoding="UTF-8"
> > > >
> > > > mode="all"
> > > >
> > > > force="true"
> > > >
> > > > />
> > > >
> > > > 
> > > >
> > > >
> > > >
> > > > The unit tests in my projects are looking nearly perfect. But I did
> see a
> > > > regression in a very specific case. I have an entity with a
> meaningful
> > > > foreign key attribute that is modeled as a primitive (int). The
> attribute
> > > > is the same column as referenced by a relationship on the same
> entity.
> > > This
> > > > was working in the previous version but isn't working now. The value
> is
> > > > just always zero for this field now. I'm not sure if this is
> supposed to
> > > be
> > > > supported.
> > > >
> > > >
> > > > On Tue, Mar 24, 2020 at 4:55 AM Nikita Timofeev <
> > > ntimof...@objectstyle.com>
> > > > wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > Here is a long-awaited 4.2.M1 release.
> > > 

Re: [VOTE] Apache Cayenne 4.2.M1 release

[Nikita Timofeev]

Hi all,

I've rolled back 4.2.M1 release and will start new voting soon.
Fix for the meaningful FK is committed now [1].
I've also checked that the latest snapshot version of the Apache RAT
[2] is ok with the "https://;, so we could use it.
I'll update docs and also will mention the maven plugin.

John, could you please check again your meaningful FK test case with
the latest cayenne snapshot build?

[1] https://issues.apache.org/jira/browse/CAY-2652
[2] 
https://repository.apache.org/content/repositories/snapshots/org/apache/rat/apache-rat/

On Sat, Mar 28, 2020 at 1:04 AM John Huss  wrote:
>
> Thanks.
>
> I figured out the problem with cgen was that I had velocity-engine-core-2.0
> instead of velocity-engine-core-2.1. Updating the jar fixed the problem.
>
>
> On Thu, Mar 26, 2020 at 12:25 PM Nikita Timofeev 
> wrote:
>
> > Thank you, John, for your thorough testing.
> >
> > 1. Seems like RAT don't like the change from "http://; to "https://;
> > in the license text. I've updated settings for the RAT maven plugin
> > (as I use it to check sources) and that works ok. Need to update
> > config for the standalone script.
> > 2. Cgen + ant. IIRC we had some problems with that and you helped a
> > lot with it. I've tested cgen task in a simple demo project and it
> > works fine for me, but I don't really know much about the Ant.
> > If you can create a demo project or help somehow else, that would be great.
> > 3. I was able to reproduce this one. Primitive type in the meaningful
> > FK really creating problems, so need to fix this.
> >
> > I'll keep this vote open in case something else comes up.
> >
> > On Thu, Mar 26, 2020 at 1:05 AM John Huss  wrote:
> > >
> > > Thanks for all your work on this. 4.2 is going to be a great release! I
> > ran
> > > all my checks on the release and almost everything passed.
> > >
> > > I don't know what changed, but I'm having a RAT problem I haven't seen
> > > before. RAT (both 0.12 and 0.13) show this header:
> > >
> > > Printing headers for text files without a valid license header...
> > >
> > >
> > > then lists basically every source file in the archive, example below.
> > When
> > > I open this file directly the license header is there, but the printout
> > > from RAT doesn't show it.
> > >
> > > =
> > >
> > > == File:
> > >
> > cayenne-4.2.M1-src/cayenne-osgi/src/test/java/org/apache/cayenne/configuration/osgi/OsgiClassLoaderManagerTest.java
> > >
> > > =
> > >
> > > /*
> > >
> > >  *
> > >
> > >  *
> > >
> > >  /
> > >
> > > package org.apache.cayenne.configuration.osgi;
> > >
> > >
> > > import org.junit.Test;
> > >
> > >
> > > import java.util.Collections;
> > >
> > >
> > > import static org.junit.Assert.assertSame;
> > >
> > > import static org.mockito.Mockito.mock;
> > >
> > >
> > > public class OsgiClassLoaderManagerTest {
> > >
> > >
> > >
> > >
> > -
> > > More importantly, I'm seeing some issues with cgen (using ant) not
> > finding
> > > templates. This wasn't happening when I tested 4.2 months ago, so it must
> > > be a more recent change.
> > >
> > > org.apache.velocity.exception.ResourceNotFoundException: Unable to find
> > > resource 'templates/v4_1/superclass.vm'
> > >
> > >
> > > 
> > >
> > >  > >
> > > superpkg="com.myapp.auto"
> > >
> > > createpropertynames="true"
> > >
> > > destDir="src"
> > >
> > > outputPattern="*.java"
> > >
> > > usepkgpath="true"
> > >
> > > encoding="UTF-8"
> > >
> > > mode="all"
> > >
> > > force="true"
> > >
> > > />
> > >
> > > 
> > >
> > >
> > >
> > > The unit tests in my projects are looking nearly perfect. But I did see a
> > > regression in a very specific case. I have an entity with a meaningful
> > > foreign key attribute that is modeled as a primitive (int). The attribute
> > > is the same column as referenced by a relationship on the same entity.
> > This
> > > was working in the previous version but isn't working now. The value is
> > > just always zero for this field now. I'm not sure if this is supposed to
> > be
> > > supported.
> > >
> > >
> > > On Tue, Mar 24, 2020 at 4:55 AM Nikita Timofeev <
> > ntimof...@objectstyle.com>
> > > wrote:
> > >
> > > > Hi all,
> > > >
> > > > Here is a long-awaited 4.2.M1 release.
> > > > JIRA tells that it has impressive 100 issues resolved.
> > > >
> > > > Release notes:
> > > > https://github.com/apache/cayenne/blob/4.2.M1/RELEASE-NOTES.txt
> > > > Maven repo:
> > > >
> > https://repository.apache.org/content/repositories/orgapachecayenne-1037/
> > > > Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.2.M1/
> > > >
> > > > Please evaluate and cast your votes.
> > > >
> > > > --
> > > > Best regards,
> > > > Nikita 

Re: [VOTE] Apache Cayenne 4.2.M1 release

[John Huss]

Thanks.

I figured out the problem with cgen was that I had velocity-engine-core-2.0
instead of velocity-engine-core-2.1. Updating the jar fixed the problem.


On Thu, Mar 26, 2020 at 12:25 PM Nikita Timofeev 
wrote:

> Thank you, John, for your thorough testing.
>
> 1. Seems like RAT don't like the change from "http://; to "https://;
> in the license text. I've updated settings for the RAT maven plugin
> (as I use it to check sources) and that works ok. Need to update
> config for the standalone script.
> 2. Cgen + ant. IIRC we had some problems with that and you helped a
> lot with it. I've tested cgen task in a simple demo project and it
> works fine for me, but I don't really know much about the Ant.
> If you can create a demo project or help somehow else, that would be great.
> 3. I was able to reproduce this one. Primitive type in the meaningful
> FK really creating problems, so need to fix this.
>
> I'll keep this vote open in case something else comes up.
>
> On Thu, Mar 26, 2020 at 1:05 AM John Huss  wrote:
> >
> > Thanks for all your work on this. 4.2 is going to be a great release! I
> ran
> > all my checks on the release and almost everything passed.
> >
> > I don't know what changed, but I'm having a RAT problem I haven't seen
> > before. RAT (both 0.12 and 0.13) show this header:
> >
> > Printing headers for text files without a valid license header...
> >
> >
> > then lists basically every source file in the archive, example below.
> When
> > I open this file directly the license header is there, but the printout
> > from RAT doesn't show it.
> >
> > =
> >
> > == File:
> >
> cayenne-4.2.M1-src/cayenne-osgi/src/test/java/org/apache/cayenne/configuration/osgi/OsgiClassLoaderManagerTest.java
> >
> > =
> >
> > /*
> >
> >  *
> >
> >  *
> >
> >  /
> >
> > package org.apache.cayenne.configuration.osgi;
> >
> >
> > import org.junit.Test;
> >
> >
> > import java.util.Collections;
> >
> >
> > import static org.junit.Assert.assertSame;
> >
> > import static org.mockito.Mockito.mock;
> >
> >
> > public class OsgiClassLoaderManagerTest {
> >
> >
> >
> >
> -
> > More importantly, I'm seeing some issues with cgen (using ant) not
> finding
> > templates. This wasn't happening when I tested 4.2 months ago, so it must
> > be a more recent change.
> >
> > org.apache.velocity.exception.ResourceNotFoundException: Unable to find
> > resource 'templates/v4_1/superclass.vm'
> >
> >
> > 
> >
> >  >
> > superpkg="com.myapp.auto"
> >
> > createpropertynames="true"
> >
> > destDir="src"
> >
> > outputPattern="*.java"
> >
> > usepkgpath="true"
> >
> > encoding="UTF-8"
> >
> > mode="all"
> >
> > force="true"
> >
> > />
> >
> > 
> >
> >
> >
> > The unit tests in my projects are looking nearly perfect. But I did see a
> > regression in a very specific case. I have an entity with a meaningful
> > foreign key attribute that is modeled as a primitive (int). The attribute
> > is the same column as referenced by a relationship on the same entity.
> This
> > was working in the previous version but isn't working now. The value is
> > just always zero for this field now. I'm not sure if this is supposed to
> be
> > supported.
> >
> >
> > On Tue, Mar 24, 2020 at 4:55 AM Nikita Timofeev <
> ntimof...@objectstyle.com>
> > wrote:
> >
> > > Hi all,
> > >
> > > Here is a long-awaited 4.2.M1 release.
> > > JIRA tells that it has impressive 100 issues resolved.
> > >
> > > Release notes:
> > > https://github.com/apache/cayenne/blob/4.2.M1/RELEASE-NOTES.txt
> > > Maven repo:
> > >
> https://repository.apache.org/content/repositories/orgapachecayenne-1037/
> > > Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.2.M1/
> > >
> > > Please evaluate and cast your votes.
> > >
> > > --
> > > Best regards,
> > > Nikita Timofeev
> > >
>
>
>
> --
> Best regards,
> Nikita Timofeev
>

Re: [VOTE] Apache Cayenne 4.2.M1 release

[Nikita Timofeev]

Thank you, John, for your thorough testing.

1. Seems like RAT don't like the change from "http://; to "https://;
in the license text. I've updated settings for the RAT maven plugin
(as I use it to check sources) and that works ok. Need to update
config for the standalone script.
2. Cgen + ant. IIRC we had some problems with that and you helped a
lot with it. I've tested cgen task in a simple demo project and it
works fine for me, but I don't really know much about the Ant.
If you can create a demo project or help somehow else, that would be great.
3. I was able to reproduce this one. Primitive type in the meaningful
FK really creating problems, so need to fix this.

I'll keep this vote open in case something else comes up.

On Thu, Mar 26, 2020 at 1:05 AM John Huss  wrote:
>
> Thanks for all your work on this. 4.2 is going to be a great release! I ran
> all my checks on the release and almost everything passed.
>
> I don't know what changed, but I'm having a RAT problem I haven't seen
> before. RAT (both 0.12 and 0.13) show this header:
>
> Printing headers for text files without a valid license header...
>
>
> then lists basically every source file in the archive, example below. When
> I open this file directly the license header is there, but the printout
> from RAT doesn't show it.
>
> =
>
> == File:
> cayenne-4.2.M1-src/cayenne-osgi/src/test/java/org/apache/cayenne/configuration/osgi/OsgiClassLoaderManagerTest.java
>
> =
>
> /*
>
>  *
>
>  *
>
>  /
>
> package org.apache.cayenne.configuration.osgi;
>
>
> import org.junit.Test;
>
>
> import java.util.Collections;
>
>
> import static org.junit.Assert.assertSame;
>
> import static org.mockito.Mockito.mock;
>
>
> public class OsgiClassLoaderManagerTest {
>
>
>
> -
> More importantly, I'm seeing some issues with cgen (using ant) not finding
> templates. This wasn't happening when I tested 4.2 months ago, so it must
> be a more recent change.
>
> org.apache.velocity.exception.ResourceNotFoundException: Unable to find
> resource 'templates/v4_1/superclass.vm'
>
>
> 
>
> 
> superpkg="com.myapp.auto"
>
> createpropertynames="true"
>
> destDir="src"
>
> outputPattern="*.java"
>
> usepkgpath="true"
>
> encoding="UTF-8"
>
> mode="all"
>
> force="true"
>
> />
>
> 
>
>
>
> The unit tests in my projects are looking nearly perfect. But I did see a
> regression in a very specific case. I have an entity with a meaningful
> foreign key attribute that is modeled as a primitive (int). The attribute
> is the same column as referenced by a relationship on the same entity. This
> was working in the previous version but isn't working now. The value is
> just always zero for this field now. I'm not sure if this is supposed to be
> supported.
>
>
> On Tue, Mar 24, 2020 at 4:55 AM Nikita Timofeev 
> wrote:
>
> > Hi all,
> >
> > Here is a long-awaited 4.2.M1 release.
> > JIRA tells that it has impressive 100 issues resolved.
> >
> > Release notes:
> > https://github.com/apache/cayenne/blob/4.2.M1/RELEASE-NOTES.txt
> > Maven repo:
> > https://repository.apache.org/content/repositories/orgapachecayenne-1037/
> > Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.2.M1/
> >
> > Please evaluate and cast your votes.
> >
> > --
> > Best regards,
> > Nikita Timofeev
> >



--
Best regards,
Nikita Timofeev

Re: [VOTE] Apache Cayenne 4.2.M1 release

[John Huss]

Thanks for all your work on this. 4.2 is going to be a great release! I ran
all my checks on the release and almost everything passed.

I don't know what changed, but I'm having a RAT problem I haven't seen
before. RAT (both 0.12 and 0.13) show this header:

Printing headers for text files without a valid license header...


then lists basically every source file in the archive, example below. When
I open this file directly the license header is there, but the printout
from RAT doesn't show it.

=

== File:
cayenne-4.2.M1-src/cayenne-osgi/src/test/java/org/apache/cayenne/configuration/osgi/OsgiClassLoaderManagerTest.java

=

/*

 *

 *

 /

package org.apache.cayenne.configuration.osgi;


import org.junit.Test;


import java.util.Collections;


import static org.junit.Assert.assertSame;

import static org.mockito.Mockito.mock;


public class OsgiClassLoaderManagerTest {



-
More importantly, I'm seeing some issues with cgen (using ant) not finding
templates. This wasn't happening when I tested 4.2 months ago, so it must
be a more recent change.

org.apache.velocity.exception.ResourceNotFoundException: Unable to find
resource 'templates/v4_1/superclass.vm'










The unit tests in my projects are looking nearly perfect. But I did see a
regression in a very specific case. I have an entity with a meaningful
foreign key attribute that is modeled as a primitive (int). The attribute
is the same column as referenced by a relationship on the same entity. This
was working in the previous version but isn't working now. The value is
just always zero for this field now. I'm not sure if this is supposed to be
supported.


On Tue, Mar 24, 2020 at 4:55 AM Nikita Timofeev 
wrote:

> Hi all,
>
> Here is a long-awaited 4.2.M1 release.
> JIRA tells that it has impressive 100 issues resolved.
>
> Release notes:
> https://github.com/apache/cayenne/blob/4.2.M1/RELEASE-NOTES.txt
> Maven repo:
> https://repository.apache.org/content/repositories/orgapachecayenne-1037/
> Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.2.M1/
>
> Please evaluate and cast your votes.
>
> --
> Best regards,
> Nikita Timofeev
>