You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <aa...@gmail.com> on 2022/07/01 16:11:10 UTC
Cayenne 5.0 - getting rid of legacy
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
Re: Cayenne 5.0 - getting rid of legacy
Posted by Andrus Adamchik <aa...@gmail.com>.
With the latest DB Sync I use Modeler much more than I did before :)
> On Jul 14, 2022, at 5:51 PM, Michael Gentry <bl...@gmail.com> 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 <aa...@gmail.com> wrote:
>
>>
>>
>>> On Jul 14, 2022, at 4:04 PM, Michael Gentry <bl...@gmail.com> wrote:
>>>
>>> On Thu, Jul 14, 2022 at 3:47 PM Andrus Adamchik <aa...@gmail.com>
>> 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
Posted by Michael Gentry <bl...@gmail.com>.
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 <aa...@gmail.com> wrote:
>
>
> > On Jul 14, 2022, at 4:04 PM, Michael Gentry <bl...@gmail.com> wrote:
> >
> > On Thu, Jul 14, 2022 at 3:47 PM Andrus Adamchik <aa...@gmail.com>
> 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
Posted by Andrus Adamchik <aa...@gmail.com>.
> On Jul 14, 2022, at 4:04 PM, Michael Gentry <bl...@gmail.com> wrote:
>
> On Thu, Jul 14, 2022 at 3:47 PM Andrus Adamchik <aa...@gmail.com> 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
Posted by Michael Gentry <bl...@gmail.com>.
On Thu, Jul 14, 2022 at 3:47 PM Andrus Adamchik <aa...@gmail.com> 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)...
Re: Cayenne 5.0 - getting rid of legacy
Posted by Andrus Adamchik <aa...@gmail.com>.
> 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 <nt...@objectstyle.com> 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 <aa...@gmail.com> 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 <bl...@gmail.com> 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 <nt...@objectstyle.com>
>>> 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 <aa...@gmail.com>
>>>> 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 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 <aa...@gmail.com>
>>>> 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
>>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Nikita Timofeev
>>>>
>>
>
>
> --
> Best regards,
> Nikita Timofeev
Re: Cayenne 5.0 - getting rid of legacy
Posted by Nikita Timofeev <nt...@objectstyle.com>.
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 <aa...@gmail.com> 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 <bl...@gmail.com> 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 <nt...@objectstyle.com>
> > 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 <aa...@gmail.com>
> >> 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 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 <aa...@gmail.com>
> >> 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
> >>>
> >>
> >>
> >> --
> >> Best regards,
> >> Nikita Timofeev
> >>
>
--
Best regards,
Nikita Timofeev
Re: Cayenne 5.0 - getting rid of legacy
Posted by Andrus Adamchik <aa...@gmail.com>.
> 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 <bl...@gmail.com> wrote:
>
> On Tue, Jul 5, 2022 at 11:46 AM Andrus Adamchik <aa...@gmail.com> 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
Posted by Michael Gentry <bl...@gmail.com>.
On Tue, Jul 5, 2022 at 11:46 AM Andrus Adamchik <aa...@gmail.com> 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
Posted by Andrus Adamchik <aa...@gmail.com>.
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 <aa...@gmail.com> 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 <bl...@gmail.com> 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 <nt...@objectstyle.com>
>> 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 <aa...@gmail.com>
>>> 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 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 <aa...@gmail.com>
>>> 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
>>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Nikita Timofeev
>>>
>
Re: Records and result auto-mapping
Posted by Andrus Adamchik <aa...@gmail.com>.
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 <nt...@objectstyle.com> 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<ArtistDataWrapper> 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 <aa...@gmail.com> 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<MyEntityDTO> 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: Records and result auto-mapping
Posted by Nikita Timofeev <nt...@objectstyle.com>.
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<ArtistDataWrapper> 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 <aa...@gmail.com> 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<MyEntityDTO> 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
Records and result auto-mapping
Posted by Andrus Adamchik <aa...@gmail.com>.
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<MyEntityDTO> 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
Posted by Michael Gentry <bl...@gmail.com>.
On Tue, Jul 5, 2022 at 11:27 AM Andrus Adamchik <aa...@gmail.com> wrote:
> 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.
>
Well, there IS a common superclass... If using a
convention-over-configuration event-name scheme (like Tapestry), you could
have onPostAdd(), onPrePersist(), etc, in the superclass.
1. Commonly used PostAdd to "repair" schemas from year-to-year. Say the
schema changed between 2014 and 2015. The UI/app only supported year 2015,
but needed to load in prior years. The PostAdd would then update the
objects on the fly to be compatible with 2015 so you could view, copy,
edit, save, etc. As the schema evolved, the PostAdds would dynamically
repair the objects. Worked well and didn't require even more complex DB
migration updates. These updates could be far more complex than simple
default values.
2. I can't believe you don't have the modeler open! :-)
Re: Cayenne 5.0 - getting rid of legacy
Posted by Andrus Adamchik <aa...@gmail.com>.
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 <bl...@gmail.com> 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 <nt...@objectstyle.com>
> 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 <aa...@gmail.com>
>> 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 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 <aa...@gmail.com>
>> 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
>>>
>>
>>
>> --
>> Best regards,
>> Nikita Timofeev
>>
Re: Cayenne 5.0 - getting rid of legacy
Posted by Michael Gentry <bl...@gmail.com>.
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 <nt...@objectstyle.com>
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 <aa...@gmail.com>
> 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 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 <aa...@gmail.com>
> 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
> >
>
>
> --
> Best regards,
> Nikita Timofeev
>
Re: Cayenne 5.0 - getting rid of legacy
Posted by Andrus Adamchik <aa...@gmail.com>.
> On Jul 5, 2022, at 2:00 PM, Nikita Timofeev <nt...@objectstyle.com> 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: Cayenne 5.0 - getting rid of legacy
Posted by Andrus Adamchik <aa...@gmail.com>.
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 <jo...@gmail.com> 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 <aa...@gmail.com>
> 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 <nt...@objectstyle.com>
>> 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 <aa...@gmail.com>
>> wrote:
>>>>
>>>>
>>>>
>>>>> On Jul 5, 2022, at 2:00 PM, Nikita Timofeev <nt...@objectstyle.com>
>> 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
Posted by John Huss <jo...@gmail.com>.
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 <aa...@gmail.com>
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 <nt...@objectstyle.com>
> 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 <aa...@gmail.com>
> wrote:
> >>
> >>
> >>
> >>> On Jul 5, 2022, at 2:00 PM, Nikita Timofeev <nt...@objectstyle.com>
> 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
Posted by Andrus Adamchik <aa...@gmail.com>.
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 <nt...@objectstyle.com> 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 <aa...@gmail.com> wrote:
>>
>>
>>
>>> On Jul 5, 2022, at 2:00 PM, Nikita Timofeev <nt...@objectstyle.com> 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
Posted by Nikita Timofeev <nt...@objectstyle.com>.
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 <aa...@gmail.com> wrote:
>
>
>
> > On Jul 5, 2022, at 2:00 PM, Nikita Timofeev <nt...@objectstyle.com> 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
Posted by Andrus Adamchik <aa...@gmail.com>.
> On Jul 5, 2022, at 2:00 PM, Nikita Timofeev <nt...@objectstyle.com> 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
Posted by Nikita Timofeev <nt...@objectstyle.com>.
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 <aa...@gmail.com> 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 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 <aa...@gmail.com> 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
>
--
Best regards,
Nikita Timofeev
Re: Cayenne 5.0 - getting rid of legacy
Posted by Michael Gentry <bl...@gmail.com>.
As the blamee for the password encoders, I feel the use-case has been
overcome by events for quite some time now. +1
Also +1 for Spring/Boot integration, even if minimal, simply due to
popularity.
On Sun, Jul 3, 2022 at 7:17 AM Andrus Adamchik <aa...@gmail.com> 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 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 <aa...@gmail.com> 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
>
>
Re: Cayenne 5.0 - getting rid of legacy
Posted by Andrus Adamchik <aa...@gmail.com>.
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 <aa...@gmail.com> 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