Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Attribute en/decoding strategy of the EntityManager is not configuable #33

Open
bertramn opened this issue Apr 23, 2013 · 3 comments
Open

Comments

@bertramn
Copy link

The decoding strategy used by the EntityManager to store integer or floats is not configurable and the default mechanism makes the content in the atrribute field pretty much non-interpretable.

Why not:

  1. Make the type serialization of attributes configurable
  2. Why did you not use the AWS en/decode tools? They are provided by com.amazonaws.services.simpledb.util.SimpleDBUtils.
@arielvardi
Copy link

New to simeplejpa and seeing the same thing. Would love some pointers on best practices to serialize/deserialize these fields.

@treeder
Copy link
Member

treeder commented Apr 24, 2013

SimpleJPA was probably made before SimpleDBUtils was available and I believe the encoding we used was common practice to ensure it was padded properly and sortable. For example: http://aws.amazon.com/articles/1232

Happy to take pull requests though if you want to make it configurable.

@bertramn
Copy link
Author

Inspecting the Hibernate type mapping support would be a good start. Hibernate has a default strategy to map types to the underlying Dialect. There is a default strategy for type mapping and if specified otherwise a custom one.

Them main reason for needing the choice is SimpleDB stores everything as text and hence for searching and ordering, one will need to convert the types into lexical formats that will allow proper ordering.

E.g. for integer values we could calculate an offset (as currently done by the simplejpa entitymanager) that is lexically sortable.

// default strategy @Type(type = "org.spaceprogram.simpejpa.IntegerOffsetType")
@Column(name = "some_int_field")
private int someIntegerField;

Input: 2
Result: 09223372036854775810

Then we could create other type mapping strategies for the integer like below:

@Type(type = "org.spaceprogram.simpejpa.IntegerPaddedType")
@Column(name = "some_int_field")
private int someIntegerField;

Input: 2
Result: 0000000000000000002

Internalized dates is another area where this could be beneficial. E.g if we have dates with timezone offset we need to convert them all to UTC times to be properly sortable. Or sometimes they need to be local, as in show me all flights that depart prior to 6:00am at airport local time across the US.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants