Adding, updating and deleting fields in app engine's datastore
jbdhl
engine's datastore by accident. Assume that a class, say MyClass, has
a number of "persistent" members, e.g.
...
int a
int b
int c
...
and assume a number of MyClass objects have been stored in app
engine's persistent storage. Now, what will happen if...
1) a new persistent member variable, int d, is *added* to MyClass?
The old objects in datastore did not have this variable, so what will
their d-value be when they are fetched from datastore?
2) a persistent member variable, int b, is *removed* from MyClass?
I guess the b field will be removed from all stored MyClass objects?
If not, what will happen if b is re-added at some later point in time?
Will the stored MyClass objects now get their old b-value back?
3) the type of a persistent member variable is changed, e.g. if a
is converted to a String? What will the value of a be when the already
stored objects are fetched from datastore?
Jeff Schnitzer
Objectify, Twig, SimpleDS, Slim3, etc...
I will describe what Objectify does (others can comment on their frameworks):
On Fri, Mar 26, 2010 at 1:30 AM, jbdhl <jbirk...@gmail.com> wrote:
>
> 1) a new persistent member variable, int d, is *added* to MyClass?
> The old objects in datastore did not have this variable, so what will
> their d-value be when they are fetched from datastore?
The 'd' field will be ignored by Objectify. You can initialize it in
your java code to whatever you want. When you put() the entity, the
'd' will be saved as normal.
> 2) a persistent member variable, int b, is *removed* from MyClass?
> I guess the b field will be removed from all stored MyClass objects?
> If not, what will happen if b is re-added at some later point in time?
> Will the stored MyClass objects now get their old b-value back?
The 'b' data will be ignored by Objectify when you load your entity.
The data will continue to live in the datastore *unless* you put() the
new, b-less entity.
If you do not write to the dataset, you can re-enable 'b' on your
entity and get the data back. If you wrote to part of your dataset
but then changed your mind and re-enabled 'b', you will get the data
that still remains. Any rewritten entities will be b-less in the
datastore, so loading the entity will be like part 1) above - the 'b'
field will be left in its default state.
> 3) the type of a persistent member variable is changed, e.g. if a
> is converted to a String? What will the value of a be when the already
> stored objects are fetched from datastore?
To some extent, the answer is "it depends". There are some simple
conversions that always work; for example, any data type can be
converted to a String.
The proper way to do conversions in Objectify is to use an @AlsoLoad
method. Here's an example of converting 'a' to a hex String:
class MyEntity {
@Id Long id;
String a;
public void importOldA(@AlsoLoad("a") Object oldA) {
if (oldA instanceof String)
this.a = (String)oldA;
else
this.a = Integer.toHexString(((Number)oldA).intValue());
}
}
When you deploy your code, the natural churn will start converting int
a's to String a's while your application runs normally. You can fire
off a task queue batch job that simply queries for all MyEntity
objects and re-put()s them.* After you're sure that you've converted
your entire dataset, you can remove the importOldA() method from your
entity. No downtime required.
BTW, you'll probably more likely to get a response from someone with
JDO/JPA knowledge on the appengine-java list.
* There are some nuances to this. If your data has a high churn rate,
you'll want to skip already-converted entities (add a '@Transient
boolean staleFormat;' field and set it from importOldA()). You might
also want to perform each single-entity get()/put() in a transaction
so that you don't end up clobbering other writes.
Jeff
jbdhl
JDO was *the* way to access the datastore... Are there some comparison
of the access methods somewhere?
I I'll try to post my questions to the appengine-java list also, as
you suggested.