KeyValuePair needs to store a Blob not a generic Object
Bug #744035 reported by
Matt Giuca
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MUGLE |
Fix Released
|
Critical
|
Prageeth Silva |
Bug Description
The current KeyValuePair class has its 'value' as an Object. This will only work for Objects that have been specially marked for JDO persistence. We want to allow any plain-old-Java serializable objects to go in here.
Therefore, change the 'value' field to a com.google.
Changed in mugle: | |
status: | Triaged → Fix Committed |
Changed in mugle: | |
status: | Incomplete → Triaged |
status: | Triaged → In Progress |
Changed in mugle: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
I've got a problem with this, and it kind of casts doubt on the whole "database classes are the same ones exposed to the client" concept. I tried changing the 'value' field of KeyValuePair to a Blob, but of course, I am now getting a gwtc compile error -- there is no Blob class in JavaScript!
Really, the client version of the KeyValuePair should have an Object (already deserialised), while the database/server version should have a Blob (serialised for the database storage). With the current architecture, there is no way for me to ever use any type in the database which is not a standard Java type (such as Blob, Text, User, etc). This makes me nervous about the whole concept. Perhaps we should just be providing a much simpler API (similar to the dev-api) which simply lets you query individual properties of each object, rather than taking a copy of the whole thing.
In any event, I don't know how to solve this present problem. Any thoughts?