`options.autoCreate` not working

[stephenplusplus]

Tried with database.get({ autoCreate: true }) and instance.get({ autoCreate: true }). They both return the standard 404 error for the resource not existing.

[stephenplusplus]

I put a bunch of thoughts about how to handle this in my PR, but I'm going to move them here, since we might decide that PR is the wrong solution.

These methods say they support autoCreate, but they aren't working currently. I went off to fix that, then realized... maybe they shouldn't support auto-create functionality, because the response arguments (and how to handle them) would be different depending on if the resource existed or not.

For example, this code doesn't currently work, but if it did, it would be like this:

function onDatabase(database) {
  // do whatever with `database`
}

database.get({ autoCreate: true }, function(err, database, operation, apiResponse) {
  if (err) {
    // handle error
    return
  }

  if (operation instanceof Spanner.Operation) {
    operation
      .on('error', handleCreateFailed)
      .on('complete', () => onDatabase(database))
  } else {
    onDatabase(database)
  }
})

I think that's not so great, and kills the point of having one method simply "get or create", and when it's done, you have a database-- no extra logic to worry about.

We could hide this from the user-- their callback would be called either right away, when we confirm it exists, or eventually, after the create operation completes. We would simply subscribe to the operation internally, and execute the user's callback after it complete. The downside to that is hidden behavior (we could document it), as well as inconsistent response times to the user (one near-instant, the other eventual).

What do you all think? @callmehiphop @alexander-fenster

[callmehiphop]

IMO if a user is using the autoCreate option, it's because they don't want to go through the hassle of checking the error code and then creating the resource, etc. Something tells me if they're looking for convenience then they're not going to mind if we abstract away the operation as well.

The downside to that is hidden behavior (we could document it)

I think that if the user requires a finite level of control we would just direct them to exists() and allow them to handle it how they see fit. IMO its ok to have hidden functionality as long as there is a lower level counterpart.

as well as inconsistent response times to the user (one near-instant, the other eventual).

I think if the user is using autoCreate then they have to be aware that the resource might not exist, so longer response times should be expected.

[stephenplusplus]

SGTM. Just want to see if @alexander-fenster agrees 👍

[alexander-fenster]

My understanding has always been that we should make common operations easy, and complicated operations possible. So I see nothing wrong in hiding some details (e.g. allowing {autoCreate: true} and performing some hidden stuff under the hood), if (a) the hidden stuff is well-documented, and (b) it's possible for the user to choose not to use {autoCreate: true} and control the creation manually. As I understand the proposed solution satisfies both (a) and (b), so I'm OK with it.

[stephenplusplus]

Alright, done! #133