How to store key value pairs in App Engine datastore?

1
votes

I have an entity with 2 properties: UserId(String) and RSSSubscriptions(String). Instances of this class will be storing in App Engine Datastore.

Where RSSSubscriptions should be a key value pair like "Site1: Feed1", "Site2: Feed2".

Since datatypes like Hashmaps are not persistable I am forced to keep this data in a String format. Currently I have stored it as a string type with JSONArray format. Say, "[{"Site1: Feed1"}, {"Site2: Feed2"}]".

My client will be an Android app. So Iam supposed to parse this string as JSON Array at client side. But I think its a bad idea to create a String with JSON format and append it with existing string, each time when user is adding new subscription. Any better Ideas?

2
google-app-engine
Juste store the two Strings in an Entity and at query time, query the datastore for entities, get the objects list and build the JSON String for your client ! For efficiency, use Memcache to cache your result, then clear your cache or update it each time you add a new subscription. - Gaël Oberson
I'm with @GaëlOberson; just one simplification: of using db entities in combination with memcache, use ndb entities which implement memcache internally. - onon15
Yes, that seems to be a good option. Thanks Gael. - Vivek Mohan

2 Answers

1
votes

You can use JSONProperty which is supported by ndb for that particular reason. In my opinion its a "hairy" solution to store Json as string and parse it back and forth. You have to be very careful to guarantee validity.

0
votes

Correct answer depends on several factors with expected number of pairs being the most important. Important to remember that there are significant costs associated with storing the pair in an entity accessed by query. There are numerous ops costs for doing a query, and there will be significant cpu time. Compare this to using a single record keyed by user id, and storing the JSON inside a TextProperty. That is one small op cost and cpu times which will likely be 10x less than a query.

Please consider these factors when deciding to go with the technically cleaner approach of querying entities. Myself, I would always use a serialized string inside a TextProperty for anything in the "thousands of pairs" volume unless there was a very high rate of deletions (and even this it likely the string approach could be better). Using a query is generally the last design choice for GAE given its high resource costs.