I’ve been a heavy user of simpleDB from past couple of months, here’s my advise to people working with date in simpleDB ::
As we all know that everything in simpleDB is a String, hence ALWAYS use a single time zone while storing dates, otherwise results might be error prone as sorting is lexicographical. I’ll recommend Joda-Time(ISO8601 format) to store dates as it provides a quality replacement for the Java date and time classes with simple API. Preferably use Zulu time zone (i.e. GMT)
Here’s how to do it ::
DateTime date = new DateTime(DateTimeZone.forID("Etc/Zulu"));
While using date in your application return time in milliseconds as it is easier to use.The code below expresses the datetime as milliseconds from 1970-01-01T00:00:00Z
String time = message.getDate();
DateTimeFormatter fmt = ISODateTimeFormat.dateTime();
DateTime dt = fmt.parseDateTime(time);
time = Long.toString(dt.getMillis());
For my app, i’m storing data in Amazon SimpleDB, but since SimpleDB has a 1024 character per attribute maximum so larger values should be stored in S3.
I’ve a class named Details which can store MultipartFile as private byte multimedia ,which is to be stored in S3. This is how to do it
private byte multimedia;
The @Lob annotation specify that the field should be persisted as a large object
Because the @Lob annotation is really just qualifying the basic mapping, it can also be accompanied by a @Column annotation when the name of the LOB column needs to be overridden from the assumed default name.
I have also marked this field to be loaded lazily, a common practice applied to LOBs that do not get referenced often.
Now simply convert your MultipartFile multimedia to a byte array as
byte mediaBytes = multimedia.getBytes();
and set this property in your object and persist it in SimpleDB. The MultipartFile will get stored in S3 with Lob-key in SimpleDB.
But if there is a chance of duplicate data, you should do this using calls to S3 rather than using @Lob annotation in order to reduce redundancy and get more control.