2
votes

I am developing a RESTfull webservice with GAE. My technology stack is focused around Jersey, Spring, and Objectify.

If you don't know Objectify is ...

“Objectify is a Java data access API specifically designed for the Google App Engine datastore. It occupies a "middle ground"; easier to use and more transparent than JDO or JPA, but significantly more convenient than the Low-Level API. Objectify is designed to make novices immediately productive yet also expose the full power of the GAE datastore.”

https://code.google.com/p/objectify-appengine/

As of now I have used Objectify Keys to store relationships in my models. Like this ...

public class MyModel {

    @Id private Long id;
    private Key<MyOtherModel>> myOtherModel;
    ...

Objectify keys provide additional power as compared to Long IDs, but they can be created from a Long ID and a MyOtherModel.class with a static method Key.create(...),

Key.create(MyOtherModel.class, id)

so I don't exactly have to store relationships as Objectify keys at the model level, I just thought it be more consistent.

The problem is I need to write a lot of additional code to create XML adapters to convert the Objectify keys to Long IDs when I serialize my model objects to JSON, and deserialize them from JSON to a Java object.

I was thinking about using Long IDs instead and creating an Objectify Key in the DAO, when I need it. Also, this would remove any Objectify specific code from anything that wasn't a DAO.

I would like some perspective from a more experienced programmer. I have never created a software of this size, several thousand lines of code that is.

Thanks a lot everyone.

2

2 Answers

2
votes

I am an in-experienced datastore/objectify developer too, so I'm just musing here.

I see your point, that replacing the Key<> type in MyModel with a Long id would simplify things for you. I would note though, that the Key<> object can contain a path (as well as a kind and an id). So, if your data model becomes more complex and MyOtherModel is no longer a root kind then your ability to generate a Key<> from a Long id breaks down.

If you know that won't happen, or don't mind changing MyModel later then I guess that isn't a problem.

For your serializing format I would suggest you use a String to hold your key or id. Your Long id can be converted to a string, and would have to be anyway for JSON (so there is no loss in efficiency), but that same string could later be used to hold the full Key too.

1
votes

You can also store them as long (or Long or String) and have a method of getMyOtherModelKey() and that can return a key after calling the static method. You can also have getMyOtherModelID() to just return the ID. This really works both ways since you can have both methods if you store a key or just the ID.

The trick comes in if you use parents in any of your models. If you do the ID alone is not enough to get the other model, you need the ID and the IDs of all the parents (and grand parents if needed). This is where Keys are nice.