Sitelet https://github.com/googleapis/google-cloud-java/issues/618
Skip to content

Remove examples if-then-else pattern #618

Description

@mziccard

In bigquery example we have the following patttern:

Table table = getTable(...);
if (table == null) {
  // create table
} else {
  // load data
}

in storage we have:

Blob blob = getBlob(...);
if (blob == null) {
  // create blob
} else {
  // get and update blob's content
}

In both cases we should remove the else branch and rather execute it after table/blob creation.

Also in datastore we do:

Entity entity = getEntity(...);
if (entity = null) {
  // create entity
} else {
  // update entity access type
}

@ajkannan @aozarov @mderka Do you guys think we should remove the else branch also for datastore's example? It makes slightly less sense to me.

Activity

  1. ajkannan commented on Feb 4, 2016

    @ajkannan

    I agree that the datastore "else" makes a more sense because users typically won't create an entity and right away modify it.

  2. aozarov commented on Feb 4, 2016

    @aozarov
    Contributor

    My first reaction was that we should not change the datastore example as it is different from the big query example in that the create (the then part of the if~else) also populate the content.

    However, this is also true for storage as both parts of the if~else also set the content.
    Indeed, the datastore example makes more sense to me as the "else" part
    is showing a way to update an entity that already exists by splitting name into
    first and last name (as oppose to a complete override of the content as we do for storage)
    but maybe that is too much to show for such example (not to mention that typically
    this should be done transactionally which would even further complicate the example).

    I do think we should modify the big query example, as suggested earlier, to remove the else
    so that in the same request we create the table if needed and upload data to it.

    Honestly, I think for storage best would be to split the example into 2 separate example
    snippets. One for get and display (meta data and content) and one for create.

    We could probably do the same for datastore or maybe add some comments to the existing
    example and even big query can add a snippet for reading data.

    Also, while at it, should resource manager example modified as well? replace just after create is not a typical usage pattern.

    Thoughts?

  3. ajkannan commented on Feb 4, 2016

    @ajkannan

    I agree with the idea to split "create" and "update" actions in the snippets for storage, datastore, and resource manager.

    This is probably slightly more convenient for users as well. If they run a snippet with create/update combined and creation works, but adding/updating data errors, a user can't simply run the same snippet over again. They'll have to modify their code because they can't create the same exact resource again.

  4. mderka commented on Feb 4, 2016

    @mderka

    I agree with both @ajkannan and @aozarov, i.e., splitting storage and data store into snippets, and modifying big query to create-if-needed-and-load meaning. All of them make sense. Same for resource manager---short snippets would be my preferred way.

  5. mziccard commented on Feb 5, 2016

    @mziccard
    ContributorAuthor

    I agree that we should split create and update, even though I wouldn't expect users to simply copy-paste snippets but rather use them to write their own first simple program.

    I will take care of fixing the snippet situation as soon as #614 is merged in. I'll also try to fix #607.

  6. self-assigned this
    on Feb 5, 2016
  7. aozarov commented on Feb 10, 2016

    @aozarov
    Contributor

    Fixed by #635

  8. added a commit that references this issue on Feb 1, 2023
  9. added a commit that references this issue on Dec 22, 2025
  10. added a commit that references this issue on Feb 24, 2026
    b296e81
  11. added a commit that references this issue on Mar 12, 2026
    f0a3e4e
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions