System limits should be available via constants

[dmcgrath]

For example, users shouldn't have to manually find the XG transaction limit (currently 25) and keep up to today if it increases, but rather just reference a client lib constant.

See: http://stackoverflow.com/questions/37200995/definition-for-the-max-number-of-entity-groups-accessed-in-an-ndb-transaction

[pcostell]

It's probably not a good idea to base the number of items in a transaction on the limit. If two (or less than 25) items need to be updated together, put them in a transaction by themselves. But if you need to update more than the limit, you can't just separate that into two commits -- now there is no consistency guarantee between the two.

The more entity groups in a transaction the more likely that transaction is to fail. Applications should probably limit the number of entity groups in a transaction to the minimum required based on the application logic.

[dmcgrath]

On the backend, I agree. It would allow UIs to be dynamically limited in a way that stays within system limits. For example, web-based game only allows 5 items to be traded due to XG limit, automatically allows 25 when we increased the limit. Trivial example, but XG limit is just a single limit, the same process could be applied to maximum string property size, batch sizes, page limits, etc. Think of it as the limits.h for a database.

[ReaperUnreal]

Just wondering if there's an update on this. I have some cases where I need to sometimes update several thousand entities and having some sort of "limits.h" would help me write code in a flexible way.

[elharo]

If it increases I doubt this library would be kept up to date with that in a timely fashion. Perhaps you could file this as a feature request for com.google.cloud:google-cloud-datastore (not in this repo despite the name) but I wouldn't expect it to happen.