Update readme about flexible env

[fredr]

From what I understand from reading this, these packages can no longer be used in combination with flexible env, since the latest App Engine Flexible env beta release.

So, the documentation should reflect that these packages are only to be used with the App Engine Standard env, and not the new Flexible env.

[xStrom]

Interesting. Is this package here on the road to deprecation? Or is it expected to not share datastore data between flex & standard, because the datastore package here and cloud.google.com/go don't seem to use compatible serialization.

[fredr]

@xStrom what is not compatible in those packages? is it that embedded struct business?

[xStrom]

We can leave the embedded struct business aside and just look at API announcement e-mails.

If you use the "cloud.google.com/go/datastore" ("cloud") package in conjunction with the "google.golang.org/appengine/datastore" or "appengine/datastore" ("appengine") packages, you should not store an Entity value Key in your embedded struct (tagged as datastore:"__key__"). The appengine datastore packages have no concept of Entity values nor their embedded Keys. If you read an Entity value with an embedded Key from an App Engine application, the Key will be dropped.

The appengine packages will continue to fail to load a slice of structs with an embedded slice field [...] An error will be returned when you try to retrieve it from Datastore. [...] If you use the cloud package in conjunction with the appengine packages, do not use this new feature.

Seems pretty explicit to me that they're not compatible. Although I'm not aware of any comprehensive list of incompatibilities.

[CaptainCodeman]

It's a different client for a different platform even though there is a lot of overlap and it shares the same language. It's really no different to all the other clients (including multiple Python options) which make their own choices on how to store things.

You pay a price if your storage structure uses some platform-specific format rather than the pieces that are common but very often you can make them work together. I have Go code that has to be aware of some of the peculiarities of what Python expects when it comes to compressed fields and embedded / repeated entities - sometimes you have to drop down to implement the PropertyLoadSaver interface to get this cross-platform compatibility.

The flex environment was originally a way to escape the AppEngine sandbox but still be running on AppEngine with the same API access, so this package used to work. Now flex is just another GCE automation and is no different to using auto-scaling groups and load balancers directly - you had to use different packages with those and now with flex too (the 'AppEngine' part of the flex naming is confusing and misleading IMO).