cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Huss <>
Subject Re: Cayenne 4.1.M1 problem
Date Thu, 16 Nov 2017 17:42:20 GMT
Yeah, right now the template is trying to be smarter than the developer by
using primitives where it should be ok.  But there are problems with this
besides the above problem due to backwards compatibility. And it is also
surprising for the developer.  So I think sticking to the type as entered
in the model is the right thing to do except in the case where a primitive
is chosen to model an attribute that allows null - then you have to use the
object wrapper instead.

On Thu, Nov 16, 2017 at 5:22 AM Nikita Timofeev <>

> Hi John,
> I've noticed this too, maybe we should change cgen templates to use
> Object type exactly as set in the model. After all it is confusing by
> itself regardless problem you mentioned.
> As for treating zero as missing PK, this can be harder as logic around
> there looks fragile to me.
> On Fri, Nov 10, 2017 at 8:10 PM, John Huss <> wrote:
> > I've found another issue with 4.1.M1 through my unit tests.  If you have:
> >
> > 1) modeled a primary key as an ObjAttribute, like customerPK
> > 2) modeled it as an object type, like java.lang.Long
> > 3) are using the Cayenne-Generated (Default) PK generation strategy
> >
> > Then Cayenne won't generate any PKs for the entity and will just use zero
> > over and over.  This can be worked around by switching the attribute's
> type
> > to a primitive (like long).
> >
> > The reason for this is that the entity template will generate the field
> as
> > a primitive long even though it was modeled because as java.lang.Long
> > because it knows that this attribute is mandatory.
> >
> > I'm ok with the template as is, but ideally the runtime would do the
> right
> > thing in this case and still generate PKs instead of using zero.
> --
> Best regards,
> Nikita Timofeev

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message