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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>: > >>> > >>>> "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 <[email protected]> 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 <[email protected]> > >>>>> 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 <[email protected]> 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 <[email protected]> > >>>>>>> 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 <[email protected]> > >>>>>>>> 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 <[email protected]>: > >>>>>>>>> > >>>>>>>>> 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 <[email protected]> > >>>>>>>>>> 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 > >>>>>>>>>> <[email protected]> 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
