Hi Maik. As I'm the one researched this, let me answer :) I failed to make BeanAccessor pluggable last time because I realized that it's deep inside code not managed by Cayenne DI. But looking again at it I wonder will this straightforward solution [1] solve your problems? And I'm really interested what is your use case? Do you perform lots of in-memory filtering and/or calculations using Cayenne Expressions?
[1] https://github.com/apache/cayenne/pull/363/files?utf8=✓&diff=unified#diff-4f928c7d2ac0e22cabde0c9732de774fR214 On Thu, Jan 31, 2019 at 7:22 PM Maik Musall <m...@selbstdenker.ag> wrote: > > Hi Andrus, > > did you have a chance to look at this yet? The reason I ask is that our > application hit the memory limit this week again (-Xmx at 96 GB), and > according to some profiling, almost half of that is used up by HashMap nodes. > So we're really eager to upgrade to Cayenne 4.1 to be able to use field-based > DataObjects, but this is preventing us from going ahead. > > Thanks > Maik > > > > > Am 25.09.2018 um 16:23 schrieb Andrus Adamchik <and...@objectstyle.org>: > > > >> "Should Cayenne by default work without prefixed accessors". > > > > My answer to this : "By default, no. As a fallback or a custom strategy, > > possibly." > > > > I actually agree about Java beans. They are almost irrelevant now. And I > > wish Java gets "data classes" and some transparent form of "properties". > > > > As things stand now though, there's no common established alternative based > > on a naming convention that we can safely hardcode without causing grief > > for someone because they didn't expect that their method would be called > > when evaluating expressions. Hence my preference for a DI fix. > > > > So how about this... Unless someone else steps in by then, let me > > brainstorm it with Nikita a couple of weeks from now and see if we can do a > > DI solution. It is not nearly as involved as it appears. > > > > Andrus > > > > > >> On Sep 25, 2018, at 9:59 AM, Hugi Thordarson <h...@karlmenn.is> wrote: > >> > >> Hi Andrus and thanks for the reply, > >> > >> allowing replacement of the entire reflection strategy is certainly nice > >> and would allow me to make the customizations I need. > >> > >> However, if it's OK with you, rather than discuss implementation details, > >> I'd like to take two steps back and revert to the more philosophical > >> design question of: > >> > >> "Should Cayenne by default work without prefixed accessors". > >> > >> What is there to be lost or gained from keeping or abandoning the > >> prefix-requirement? > >> > >> I believe I can safely assert that Cayenne works fine without accessor > >> prefixes, since I've used it that way on dozens of projects, so it looks > >> like a somewhat arbitrary limitation. It's only with the introduction of > >> field based DOs that we get a problem in a very isolated part of the > >> framework. > >> > >> It seems to me that the java ecosystem is moving towards more modern API > >> design—we've even got the architect of the Java language calling the > >> bean-style "at best a questionable -- and certainly overused -- API naming > >> convention" [http://cr.openjdk.java.net/~briangoetz/amber/datum.html > >> <http://cr.openjdk.java.net/~briangoetz/amber/datum.html>] (pardon the > >> appeal to authority, but considering where it comes from, it's probably a > >> good barometer for where java language and API design is headed). > >> > >> I'd say that the framework would be well served and future-proofed by > >> dropping the requirement for hard-coded accessor prefixes as a baked in > >> requirement. > >> > >> Cheers, > >> - hugi > >> > >> > >> > >>> On 25 Sep 2018, at 11:15, Andrus Adamchik <and...@objectstyle.org> wrote: > >>> > >>> Hi Hugi, > >>> > >>> My vote would be to do it right. There is a positive side effect that the > >>> entire reflection strategy suddenly becomes customizable. > >>> > >>> Andrus > >>> > >>> > >>>> On Sep 25, 2018, at 7:11 AM, Hugi Thordarson <h...@karlmenn.is> wrote: > >>>> > >>>> Hi Andrus, and y'all. > >>>> > >>>> I've been looking into this and it seems like a rather large change to > >>>> allow something relatively simple (allowing DataObjects to have accessor > >>>> methods that don't start with a "get"-prefix). > >>>> > >>>> Would people be diametrically opposed to just changing BeanAccessor so > >>>> that it seeks for a non-prefixed method if a prefixed one isn't found? > >>>> That modification is minimal and shouldn't affect any current users, so > >>>> I can think of. > >>>> > >>>> Cheers, > >>>> - hugi > >>>> > >>>> > >>>> > >>>>> On 20 Sep 2018, at 16:08, Andrus Adamchik <and...@objectstyle.org> > >>>>> wrote: > >>>>> > >>>>> Hi Maik, > >>>>> > >>>>> In Cayenne a canonical way to override services is via DI. A PR that > >>>>> follows that approach has a good chance of acceptance. > >>>>> > >>>>> From a quick glance, I wonder if this new DI endpoint should be a > >>>>> factory of ClassDescriptorMap (which is currently lazily created inside > >>>>> EntityResolver). We can't make ClassDescriptorMap itself DI-managed as > >>>>> it depends on the mapping state, but a factory for it can be a DI > >>>>> singleton. Inside your custom factory (a few levels down actually) you > >>>>> can provide a subclass of BeanAccessor (maybe also via its own DI > >>>>> factory?). > >>>>> > >>>>> Andrus > >>>>> > >>>>> > >>>>>> On Sep 19, 2018, at 8:35 AM, Maik Musall <m...@selbstdenker.ag> wrote: > >>>>>> > >>>>>> Hi all, > >>>>>> > >>>>>> I'd like to pull up this discussion from one year ago again. I'm > >>>>>> currently running 4.0 and testing upgrading to 4.1 using field-based > >>>>>> DataObjects, and I'm hitting the hard-coded prefixes in BeanAccessor > >>>>>> that prevent me from proceeding. > >>>>>> > >>>>>> Yes, in theory I could sigh, yield, and use "get" prefixes, but not > >>>>>> only do I dislike introducing the "get" boilerplate everywhere. I am > >>>>>> also somewhat reluctant to make a refactoring touching some 800+ files > >>>>>> in my project. To be honest, I'd rather patch BeanAccessor to personal > >>>>>> taste and deal with the consequences. > >>>>>> > >>>>>> BeanAccessor is currently always called by it's constructor. In > >>>>>> addition to the options Hugi described in his original mail in this > >>>>>> thread, I could also imagine a way to modify this to be able to inject > >>>>>> a custom Accessor implementation as an alternative. What do you think? > >>>>>> > >>>>>> And… what would happen if someone would submit a pull request actually > >>>>>> implementing one of these options? :-) > >>>>>> > >>>>>> Cheers > >>>>>> Maik > >>>>>> > >>>>>> > >>>>>>> Am 26.09.2017 um 15:32 schrieb Hugi Thordarson <h...@karlmenn.is>: > >>>>>>> > >>>>>>> Hi Michael, > >>>>>>> > >>>>>>> thanks for an honest attempt to convince me. Hard sell, though. :) > >>>>>>> > >>>>>>> I use a lot of 3rd party libraries and I've only hit one time where > >>>>>>> using the bean spec was necessary — JasperReports. That was easily > >>>>>>> fixed by providing *BeanInfo classes, in accordance with the Bean > >>>>>>> spec. But Cayenne doesn't really follow the Java Bean Spec, it just > >>>>>>> hardcodes "is", "get" and "set". > >>>>>>> > >>>>>>> As for the Eclipse thing… Well. A standard DataObject already has > >>>>>>> five methods prefixed with "get" so that list is questionable. And I > >>>>>>> don't miss this functionality. > >>>>>>> > >>>>>>> I think it's important to note that the change I'm proposing would > >>>>>>> not affect those who choose to add the prefix. It just accommodates > >>>>>>> those of us who choose not to, thus expanding the audience of the > >>>>>>> framework. > >>>>>>> > >>>>>>> Cheers, > >>>>>>> - hugi > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> On 26 Sep 2017, at 12:01, Michael Gentry <blackn...@gmail.com> wrote: > >>>>>>>> > >>>>>>>> Hi Hugi, > >>>>>>>> > >>>>>>>> Let me try to sell you on the "get" prefix. :-) > >>>>>>>> > >>>>>>>> (I did a lot of WebObjects/EOF in the past, in Objective-C and Java, > >>>>>>>> so I > >>>>>>>> understand the reluctance.) > >>>>>>>> > >>>>>>>> * The "get" prefix is part of the JavaBeans standard/contract. With > >>>>>>>> the > >>>>>>>> exception of "is" for booleans (with a little "b"). > >>>>>>>> > >>>>>>>> * There are tons of Java frameworks out there that expect and > >>>>>>>> utilize the > >>>>>>>> JavaBeans contract, so it is great for folding external frameworks > >>>>>>>> into > >>>>>>>> your code. Or folding Cayenne into other frameworks, such as > >>>>>>>> Tapestry. I > >>>>>>>> can specify Cayenne object/relationship paths in Tapestry (and other > >>>>>>>> frameworks) such as > >>>>>>>> t:value="currentItem.resourceSummary.grossCost.costs.continuingFootnote" > >>>>>>>> (real example). Since Tapestry expects the JavaBeans contract and > >>>>>>>> Cayenne > >>>>>>>> provides it, this works flawlessly. > >>>>>>>> > >>>>>>>> * In Eclipse (and others, I'm sure) I can do anObject.get[pause or > >>>>>>>> control-space] and see all the getters associated with that object. > >>>>>>>> Without the get prefix, they are spread out a-z and therefore you > >>>>>>>> can't get > >>>>>>>> as concise a list. > >>>>>>>> > >>>>>>>> mrg > >>>>>>>> > >>>>>>>> > >>>>>>>> On Tue, Sep 26, 2017 at 7:02 AM, Hugi Thordarson <h...@karlmenn.is> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> Hi all > >>>>>>>>> > >>>>>>>>> Touching on an old subject that has now become more important with > >>>>>>>>> field-based Data Objects. > >>>>>>>>> > >>>>>>>>> All of my DataObjects use accessor methods without the > >>>>>>>>> "get"-prefix. This > >>>>>>>>> was fine with Map Based data objects (where a MapAccessor would get > >>>>>>>>> property values by name), but now that my objects are field based, > >>>>>>>>> along > >>>>>>>>> comes BeanAccessor which is hardcoded to have every getter prefixed. > >>>>>>>>> > >>>>>>>>> I propose that BeanAccessor be modified to allow accessor methods > >>>>>>>>> without > >>>>>>>>> the "get"-prefix. Methods with "get" would get precedence, but if > >>>>>>>>> no method > >>>>>>>>> with a "get"-prefix exists, check for the existence of a method > >>>>>>>>> with only > >>>>>>>>> the property name. > >>>>>>>>> > >>>>>>>>> Although it's a minimal change in code, I realise it comes with a > >>>>>>>>> bit of > >>>>>>>>> potential baggage WRT testing. But this is not just to scratch a > >>>>>>>>> personal > >>>>>>>>> itch; once Cayenne 4.0 is out I want to start a large scale > >>>>>>>>> introduction of > >>>>>>>>> Cayenne to the EOF world where the get prefix is generally not > >>>>>>>>> liked and > >>>>>>>>> this change would have a big appeal. Besides, I'm not a big fan of > >>>>>>>>> the > >>>>>>>>> get-prefix myself, I find it a bit redundant :). > >>>>>>>>> > >>>>>>>>> An alternative would be to adhere to the Bean standard, and make > >>>>>>>>> BeanAccessor read bean meta information (usually specified in > >>>>>>>>> *BeanInfo > >>>>>>>>> classes) and get names of getter/setter methods from there. But > >>>>>>>>> that would > >>>>>>>>> be a much larger change than just checking for a method with > >>>>>>>>> propertyName > >>>>>>>>> if the getPropertyName method doesn't exist. > >>>>>>>>> > >>>>>>>>> What do you think? > >>>>>>>>> > >>>>>>>>> Cheers, > >>>>>>>>> - hugi > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > -- Best regards, Nikita Timofeev
