Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>If the only changes you make are additive, previously generated clients should continue to work fine. I just tested a backend and Android client and they behaved correctly when I added a field to the POJO without updating the client.</p> <p>There is a somewhat helpful <a href="https://developers.google.com/appengine/docs/java/endpoints/test_deploy#managing_your_backend_api_versions" rel="nofollow">table</a> in the documentation that gives some guidance on when you should be incrementing API versions.</p> <p>The relevant bits:</p> <blockquote> <ul> <li>When you want to introduce an incremental, but non-breaking change, keep the API version constant and deploy over the existing API.</li> <li>When you introduce a breaking change to your API, increment the API version.</li> </ul> </blockquote> <p>Adding a field to your POJO should qualify as an incremental, non-breaking change. If you change the names or types of fields, you will likely need to increment the API version.</p> <p><strong>On hosting multiple API/App Engine versions</strong></p> <p>APIs are just classes with annotations, so if you want to add a new API version, just add a new class and specify a different version number in the annotation. You're free to make use of inheritance in designing your classes (see <a href="https://developers.google.com/appengine/docs/java/endpoints/multiclass" rel="nofollow">Multiclass APIs</a>).</p> <p>If you keep the App Engine version constant (or always refer to the <code>default</code> version), the only thing that needs to change, client side, is the version of the API you are accessing. The client library builds in the version number, so if you generated a client library for <code>v1</code> of your API, it will always access <code>v1</code> of the API unless you modify the source. If you make additive changes to <code>v1</code> of the API, the client library for <code>v1</code> should continue to work (as noted above).</p> <p>If you modify both the App Engine version and API version, things get a little trickier. You can have different <code>v1</code>s of an API hosted on different (App Engine) versions of an app. By default, client libraries are going to point to the App Engine <code>default</code> version, but you can override this in the client library by changing the root URL to point to a specific version (e.g. <code>https://1-dot-myapp.appspot.com</code>).</p> <p>My recommendation is to always have code that's shipped to customers point at your <code>default</code> App Engine version (the major exception would be if you have some dogfood version of your app that can be easily updated). If you increment the App Engine version, make sure to include all API versions that you wish to support into that deployment.</p>
    singulars
    1. This table or related slice is empty.
    1. POWhat changes can I make to a cloud-endpoint (app-engine) return object before I need a new API version? (and how is that done)
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USDan Holevoet
    1. USDan Holevoet
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POWhat changes can I make to a cloud-endpoint (app-engine) return object before I need a new API version? (and how is that done)
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTBountyClose
    1. COI'm beginning to think that both adding and removing fields work just fine based on other JSON work, but I haven't tested it explicitly with Endpoints. I've seen that table but it doesn't state *how* you make (and call) specific endpoint versions while keeping old ones around.
      singulars
      1. PO
      1. USBrian White
    2. COI added some more details on hosting, calling APIs. Let me know if there are still questions.
      singulars
      1. PO
      1. USDan Holevoet
    3. COThat "Multiclass APIs" link looks to be just what I was missing. So... The client doesn't *choose* which API version; it's determined by the exported cloud-endpoint library. Newer client builds will automatically use the latest endpoint version exported in those libraries?
      singulars
      1. PO
      1. USBrian White
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload