Thanks for PR, I think I'll have some time in a few days to merge it. At first glance it seems ok.
On Sat, Apr 6, 2019 at 2:58 PM Hugi Thordarson <h...@karlmenn.is> wrote: > > Thanks Nikita, we are finally well. And yes, I'd agree that the past flu > season kind of deserves an R-rated movie :). > > I finally submitted a PR with those slight modifications to BeanAccessor to > allow for easier subclassing. If you don't see anything wrong with it it > would be awesome if it reaches 4.1. I've been using this in production for > quite some time without any problems. > > https://github.com/apache/cayenne/pull/371 > <https://github.com/apache/cayenne/pull/371> > > Cheers, > - hugi > > > > > Hi Hugi, > > > > "Flu season in Iceland" sounds like a scary movie :) Hope you are well! > > > > I've merged my pull request, so you can do yours. I don't see any > > problems with adding some flexibility to BeanAccessor while keeping it > > compatible. > > And thanks for sharing your use case. > > > > On Wed, Feb 6, 2019 at 7:15 PM Hugi Thordarson <h...@karlmenn.is> wrote: > >> > >> Hi Nikita! > >> Sorry for the late reply. Flu season in Iceland, basically just happy to > >> be alive :). > >> > >> I'm working with Maik on this and just tried out your solution. It works > >> perfectly, so thanks! > >> > >> One point though: We would of course prefer to maintain as much of the > >> behaviour already present in BeanAccessor, but it's proving a bit > >> problematic to implement our own BeanAccessor this way, since the current > >> one uses a bit of protected/friendly logic from > >> org.apache.cayenne.reflect. This can be worked around by putting our own > >> BeanAccessor implementation in a package with that name (or duplicating > >> the required logic), but obviously, that's a bit … messy. > >> > >> I propose that BeanAccessor gets a new constructor which accepts > >> isGetterName, getGetterName and setterName as parameters, that the current > >> constructor can invoke with the current values. That way, our new > >> non-prefixed BeanAccessor implementation could just subclass BeanAccessor > >> and wouldn't have to touch any logic related to reading or setting > >> property values, it would only pass in our preferred property name > >> structure. > >> > >> At least that's one idea. If you agree with this, I'd be more than happy > >> to submit a PR with that modification once your PR has been merged. > >> > >> Cheers, and thanks again, > >> - hugi > >> > >> > >> > >>> On 4 Feb 2019, at 13:12, Nikita Timofeev <ntimof...@objectstyle.com> > >>> wrote: > >>> > >>> 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 > >> > > > > > > -- > > Best regards, > > Nikita Timofeev > -- Best regards, Nikita Timofeev
