cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hugi Thordarson <h...@karlmenn.is>
Subject Re: Allowing property getters without a "get" prefix on DataObjects
Date Wed, 06 Feb 2019 16:25:12 GMT
Sorry, I neglected to answer your question about the use case.

Yes, we do quite a bit of work using both in-memory sorting using Ordering and filtering by
Expression. Property.getFrom(...) is also very valuable when constructing dynamic UIs.

Although these things can certainly be performed using different means, being able to use
the same object structures to perform both DB work and in-memory work is extremely useful,
especially when it comes to complex object graphs with deep queries (long object paths).

Cheers,
- hugi


> On 4 Feb 2019, at 13:12, Nikita Timofeev <ntimofeev@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 <maik@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 <andrus@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 <hugi@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 <andrus@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 <hugi@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 <andrus@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 <maik@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 <hugi@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 <blacknext@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
<hugi@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


Mime
View raw message