Hmm not sure. The point is why needing to make explicit something already explicit? If a converter is provided then it is @Persistent no? Any case I miss? Le 21 mai 2015 16:27, "Rick Curtis" <curti...@gmail.com> a écrit :
> I think the more appropriate solution (and in line with the 2.1 spec) would > be to require these types to be listed in the <class> section of the > persistence-unit definition. I *think* the 2.1 spec requires this for > converters. Then perhaps we could remove the requirement of having the > @Persistent annotation? > > On Thu, May 21, 2015 at 2:48 AM, Romain Manni-Bucau <rmannibu...@gmail.com > > > wrote: > > > Le 21 mai 2015 04:02, "Rick Curtis" <curti...@gmail.com> a écrit : > > > > > > > not sure why it is not activated by default then, any idea? > > > > > > I couldn't tell you off the top of my head, but I would guess if > someone > > > spent the time to state it needs to be @Persistent in the doc.... there > > is > > > most likely a decent reason. Is this causing some sort of a problem for > > you? > > > > > > > Was testing some pre-attribute converter solution and was surprise than > it > > goes in db by default but serialized even being a string. This breaks sql > > updates then. > > > > > On Wed, May 20, 2015 at 5:13 PM, Romain Manni-Bucau < > > rmannibu...@gmail.com > > > > > > wrote: > > > > > > > Right @Persistent solves it, not sure why it is not activated by > > default > > > > then, any idea? > > > > > > > > > > > > Romain Manni-Bucau > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > > > <http://rmannibucau.wordpress.com> | Github < > > > > https://github.com/rmannibucau> | > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber > > > > <http://www.tomitribe.com> > > > > > > > > 2015-05-21 0:05 GMT+02:00 Rick Curtis <curti...@gmail.com>: > > > > > > > > > > seems today only serialization can be used using > > > > @Externalizer/@Factory. > > > > > > > > > > I don't think that's the case[1][2]. For some reason I couldn't > > cleanly > > > > > apply your patch to trunk, but can you try adding a @Persistent > > > > annotation > > > > > to your CustomDate ? Also, take a look at > > > > > org.apache.openjpa.persistence.fields.TestEnumSets > > > > > to see if it is close to the scenario you're looking at trying to > > fix? > > > > > > > > > > [1] If your externalized field is not a standard persistent type, > you > > > > must > > > > > explicitly mark it persistent. In OpenJPA, you can force a > persistent > > > > field > > > > > by annotating it with org.apache.openjpa.persistence.Persistent > > > > > < > > > > > > > > > > > > > > http://ci.apache.org/projects/openjpa/trunk/docbook/manual.html#ref_guide_meta_jpa_persistent > > > > > > > > > > > annotation. > > > > > > > > > > [2] > > > > > > > > > > > > > > > > > > > http://ci.apache.org/projects/openjpa/trunk/docbook/manual.html#ref_guide_pc_extern > > > > > > > > > > On Wed, May 20, 2015 at 8:38 AM, Romain Manni-Bucau < > > > > rmannibu...@gmail.com > > > > > > > > > > > wrote: > > > > > > > > > > > Hi guys, > > > > > > > > > > > > seems today only serialization can be used using > > > > @Externalizer/@Factory. > > > > > > However when both rely on the same type and the type is easy > enough > > > > (let > > > > > > take the so common String example) I think we can map it 1-1 in > the > > > > > > database. Advantage is you can use any sql too to update the > > values. > > > > > > > > > > > > Opened a task and proposed a patch for it > > > > > > https://issues.apache.org/jira/browse/OPENJPA-2589 > > > > > > > > > > > > wdyt? > > > > > > > > > > > > Romain Manni-Bucau > > > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > > > > > <http://rmannibucau.wordpress.com> | Github < > > > > > > https://github.com/rmannibucau> | > > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber > > > > > > <http://www.tomitribe.com> > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > *Rick Curtis* > > > > > > > > > > > > > > > > > > > > > -- > > > *Rick Curtis* > > > > > > -- > *Rick Curtis* >