Is it possible to store arraylists within arraylists in the AppEngine datastore? I found this topic from 2010: Datastore list of lists that recommends using pickle, but I'd like to use as few packages as possible.
Have there been any updates on AppEngine's datastore that would allow this?
Our arraylist inside arraylist has 5 or so layers, if that is important.
Thanks.
No, nothing has been added that would specifically make this any easier. I think that my advice in the question that you cited still stands.
Related
I'm searching for the best possible cloud based database solution, which can be accessed via Matlab. In the best case I could store higher level variables, e.g., cells and query items within them with a fuzzy search. Maybe there is the possibility to query such a DB with python code from Matlab?
MongoDB and Cassandra can be accessed via the DB toolbox of Matlab but don't allow for querying within container variables as far as I know. DynamoDB and DocumentDB can't store such variables as far as I know. There also maybe a go-to solution that I dont know about or just couldn't think of myself.
(Also the pricing isn't very transparent as well)
Maybe someone has an idea or experience with this kind of problem?
Thank you very much in advance,
Leo
I am developing a project on my Final year at uni and this will be an Android application.
Basically, the "company" updates the database with jobs to be done around the country. Its field workers will use the app to display the jobs available in their location. Workers then select the jobs they are committing to do and send the selection back to database.
I would like to use Google App Engine for that and I am just studying it at the moment.
I came across two methods how to store the data on GAE: Datastore and Cloud SQL.
Personally, I would like to use NoSql Datastore in order to experiment and learn it.
What would you suggest me to use for my use case?
What are the pros and cons of using both mentioned methods?
If I go with Google Datastore, is this guide good for me to start with? https://developers.google.com/appengine/docs/java/datastore/
I would say both will work. If you want to discover the Google Datastore then go for it.
But I would suggest you have a look at Objectify, this library is excellent to make you the things easier with this technology.
go with Google App engine Database. its very efficient to use. yes tat document is enough to start.
I have seen a little of this in stack overflow but I am wondering if there is any reason to use the DB entity model and what the specific pros and cons of using on or the other are.
I have read the ndb is a little faster and that it helps with caching. They have a good bit of info in the docs but don't really straight out say that ndb is better. At least I haven't found that yet.
As far as I can tell ndb is an evolution of db, kept seperate to maintain compatability.
Have a look at the cheat sheet, it details the main differences
https://docs.google.com/document/d/1AefylbadN456_Z7BZOpZEXDq8cR8LYu7QgI7bt5V0Iw/mobilebasic
But it does not mention the other features such as computed properties.
If you are starting a new project I see no reason not to use ndb and every reason to.
EDIT: Alt link for document: https://docs.google.com/document/d/1AefylbadN456_Z7BZOpZEXDq8cR8LYu7QgI7bt5V0Iw/edit#
I am exploring web development with Google AppEngine (Java). My application has a very basic data storage requirement that is well suited to AppEngine's 'map' like datastore.
The basic unit is one class that will have member variables that will be written or read from the database per transaction (this is because it interacts with an Android app).
I am considering using Objectify for interfacing.
My questions are : What happens if I later change the size (number of variables) in my base class ? I know AppEngine isn't typed but will Objectify cause any problems if some variables are available for some keys and not for others ?
This is addressed extensively in the manual:
http://code.google.com/p/objectify-appengine/wiki/IntroductionToObjectify#Migrating_Schemas
The short answer is that you can add and remove fields at will. In addition, there are facilities for more sophisticated transformations of data.
If you decide to move from the Objectify framework to the Low-level API later, you won't have a problem. App engine's datastore is typed, but not with all the Java types. I don't know whether you'd be able to get JDO or JPA to work without reading and re-writing all your data, but I think you probably would.
Objectify 4's method of storing a Map is pretty nice - storing properties as something like "fieldname-mapkey"
I am experimenting with App engine. One of my stumbling blocks has been the support for managed relations or lack there off, this is further compounded by the lack of join support.
Without getting into details of the issues I have run into (which I will post under different topic), I would like to ask two things.
1. Has any one of you used managed relations in something substantial. If so if you can share some best practices that will help.
2. Is there any good comprehensive example(s) that you have come across which you can point me at.
Thanks in advance.
I think this answer might disappoint you, but before you develop on the app engine you should read it anyway, and confirm this in the docs.
No. No one on the app engine has used managed relations for anything 'substantial', simply because Bigtable is not built for managed relations. It is a sharded and sorted array, and as such is a very different kind of data structure than what you would normally use.
Now there are attempts to set up managed relationships - the GAE/Java team is pushing JDO features that come close to this, and there's more info on this blog, but this simply isn't the natural state of things on the app engine, and you'll very quickly run into problems if you decide to spend too much time wrapping yourself in a leaky abstraction.
Its a lot easier to actually look at what bigtable really is - there are a ton of videos on the google i/o pages for 2010 and 2009 that do a fantastic job of explaining that, and then figure out ways to map your problem according to the capabilities of the datastore. It may sound unreasonable, but think about it... the GAE is a tool that can do certain things exceedingly well, and if you can figure out your problem in terms of ideas like object stores, sets, merge joins, task queues, pre-computation and caching, then you can use this tool to kick ass.