Re: Primary key string ids are stripped

[Pawel Veselov <pa...@gmail.com>]

Hello.

Sorry, I didn't notice these responses until now.

Yes, exactly as Matthew said. The primary key must be a string, only
primary keys are affected.

@Entity public class X { @Id String p; }

You save this entity with value "p" of "0\t" (tab character), you
won't be able to find it using EntityManger.find(...)
There would be no generation type on the ID. Enhancement strategy and
generation strategy is not important, the value is saved correctly to
the database.
But as the primary key value that you specify during find() travels
through the code, it is stripped of leading/trailing whitespaces at
some point.

I attempted to find the point where it's done quickly, but I can't,
it's been too long since I debugged this. Let me know if you need me
to find exactly where it happens.
There is some factory that is attached to massage the primary key
passed into the find() method, for some special cases, and that
factory ends up stripping the strings.

Thank you,
  Pawel.

On Sat, Oct 27, 2018 at 5:08 PM Mark Struberg <st...@yahoo.de.invalid> wrote:
>
>  'not able to find it right after'
> +1 to what Matthew said. We need a bit more info.
> Say you have the following code:
> Customer c = new Customer();c.setName("Bla");em.persist(c);Long id = c.getId();
> is this about what you did?
> Plus: what enhancement strategy do you use? And what @GenerationType if any on the @Id?
>
> There are now so many different scenarios out there that it might be better if you could provide parts of your code in a sample.
> LieGrue,strub
>
>     On Friday, 26 October 2018, 09:55:37 CEST, Matthew Broadhead <ma...@nbmlaw.co.uk.INVALID> wrote:
>
>  can you give a small example?  do you mean when the field annotated @Id
> is a String then find returns null?
>
> On 25/10/2018 02:34, Pawel Veselov wrote:
> > Hello.
> >
> > I just found out, the hard way, that OpenJPA strips the string entity
> > IDs when doing find().
> > It doesn't strip those values when saving entities with corresponding
> > primary keys.
> > Is there a particular reason for this? It sounds weird to create an
> > entity with primary key "0\t", but then not be able to find it right
> > after....
> >
> > Thank you,
> >    Pawel.
>
>



-- 
With best of best regards
Pawel S. Veselov