GAE Java SDK 1.2.1 released
Of the major innovations:
1. Support for non-indexed properties of any type of database (as Text)
2. Response size increased to 10 megabytes
3. Support Thread.setContextLoader ()
Fixed various bugs for both the SDK and ORM.
Regarding (1), be vigilant - as you know, without specifying the field that it should not be indexed, the datastore builds forward and inverse indices in 2 "tables" of the bigtable (without this, it is impossible to do a sample with a criterion for this field). The feature seems to reduce the amount of data in the repository, but when declaring a field as indexed in the model, the repository will not build indexes automatically (only for those data that were placed after the deployed application). The situation is reversed, if there was already data with the property being indexed, the indexes will not be automatically deleted if the property changes to non-indexable in the model. But the data will not be added to the index.
')
Therefore, you will have to use remote_api and update each entry in accordance with the new model. For large data sets it is very expensive, both in update time and in CPU. Why the Googlers did not make the mechanism as described in this article (how composite indexes are built) - for me, while a mystery, it may be in a hurry.
When using this option for many applications, in addition to reducing the use of storage space, it is also expected to reduce the CPU consumption required to automatically add data to 2 indexes for each property. Truth here there is an active discussion concerning this new feature.
The innovations that already exist in the Python SDK 1.2.2 are not added yet:
1. Persistent User ID - it’s a unique ID for Google Accounts.
2. Support key-only requests (insanely convenient for mass deletion, etc.)
3. Support in UrlFetch request time (deadline)
4. Support in UrlFetch User-Agent Header
Well, it’s imperative that it’s not yet ready (remote_api, and most importantly local dataviewer) - it’s going to be in the next version, which will be soon (I hope until May 27, when they have Google I / O). Well, of course I want the rest of the roadmap features :)
PS The eclipse plugin has also been updated, but what has changed there is unknown at the time of this writing.
1. Support for non-indexed properties of any type of database (as Text)
2. Response size increased to 10 megabytes
3. Support Thread.setContextLoader ()
Fixed various bugs for both the SDK and ORM.
Regarding (1), be vigilant - as you know, without specifying the field that it should not be indexed, the datastore builds forward and inverse indices in 2 "tables" of the bigtable (without this, it is impossible to do a sample with a criterion for this field). The feature seems to reduce the amount of data in the repository, but when declaring a field as indexed in the model, the repository will not build indexes automatically (only for those data that were placed after the deployed application). The situation is reversed, if there was already data with the property being indexed, the indexes will not be automatically deleted if the property changes to non-indexable in the model. But the data will not be added to the index.
')
Therefore, you will have to use remote_api and update each entry in accordance with the new model. For large data sets it is very expensive, both in update time and in CPU. Why the Googlers did not make the mechanism as described in this article (how composite indexes are built) - for me, while a mystery, it may be in a hurry.
When using this option for many applications, in addition to reducing the use of storage space, it is also expected to reduce the CPU consumption required to automatically add data to 2 indexes for each property. Truth here there is an active discussion concerning this new feature.
The innovations that already exist in the Python SDK 1.2.2 are not added yet:
1. Persistent User ID - it’s a unique ID for Google Accounts.
2. Support key-only requests (insanely convenient for mass deletion, etc.)
3. Support in UrlFetch request time (deadline)
4. Support in UrlFetch User-Agent Header
Well, it’s imperative that it’s not yet ready (remote_api, and most importantly local dataviewer) - it’s going to be in the next version, which will be soon (I hope until May 27, when they have Google I / O). Well, of course I want the rest of the roadmap features :)
PS The eclipse plugin has also been updated, but what has changed there is unknown at the time of this writing.
Source: https://habr.com/ru/post/59553/
All Articles