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 <aadamc...@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 <blackn...@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 <ntimof...@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 <aadamc...@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 <aadamc...@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 >>> >
