Re: Allowing property getters without a "get" prefix on DataObjects

[Nikita Timofeev]

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  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 
> 
>
> 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  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  
> >>> 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=✓=unified#diff-4f928c7d2ac0e22cabde0c9732de774fR214
> >>>
> >>> On Thu, Jan 31, 2019 at 7:22 PM Maik Musall  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 :
> >
> >> "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  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.
> >>
> >> 

Re: Cayenne 4.2 StringProperty—implement ComparableProperty?

[Nikita Timofeev]

Hi,

Missed this thread.
I just didn't imagine that there is a use case for that. But as long
as it is supported by DBs, I think this should be supported by Cayenne
as well.

On Mon, Mar 4, 2019 at 4:24 PM Hugi Thordarson  wrote:
>
> Hi all.
> I've been experimenting a little with Cayenne 4.2. It looks lovely and I 
> can't wait to start using it.
>
> One thing I bumped into is that StringProperty does not implement 
> ComparableProperty. Although I'd personally never design a DB or a system 
> that requires this, I work with a couple of legacy systems that use 
> comparison of string fields ("someString">"otherString" etc.). Doing a little 
> googling seems to show that it's also a bit of a practice and widely 
> supported by DBs.
>
> So… Do you think StringProperty should implement ComparableProperty? I'm torn 
> myself. It feels wrong—but if it's supported by DBs and widely used, perhaps 
> the Cayenne API should allow for that?
>
> Cheers,
> - hugi



-- 
Best regards,
Nikita Timofeev