Customize gcloudCommand of LocalDatastoreHelper

[vtnlinh95]

I am using Spring Cloud GCP. It has the auto-configuration to start datastore emulator when starting the app engine devserver. However, when I read through the set up of LocalDatastoreHelper, I could see that the gcloudCommand is hard-coded. Are there any ways that I can customize the options of gcloudCommand ?

    List<String> gcloudCommand = new ArrayList<>(Arrays.asList(GCLOUD_CMD_TEXT.split(" ")));
    gcloudCommand.add(GCLOUD_CMD_PORT_FLAG + "localhost:" + getPort());
    gcloudCommand.add(CONSISTENCY_FLAG + consistency);
    gcloudCommand.add("--no-store-on-disk");
    GcloudEmulatorRunner gcloudRunner =
        new GcloudEmulatorRunner(gcloudCommand, VERSION_PREFIX, MIN_VERSION);
    if (gcdPath != null) {
      gcloudCommand.add("--data-dir=" + gcdPath.toString());
    }

I want to remove the option --not-store-on-disk and would like to change the --data-dir to my local folder.
Moreover, could you help me to find the location of the current data-dir. I do not know where it is.
Thanks

[BenWhitehead]

Hi @vtnlinh95 thanks for the question.

Regarding adding the ability for you to specify your own flags, this is something I'll have to spend some more time looking into to figure out how Spring Cloud GCP is using LocalDatastoreHelper, but it sounds like a good idea to me.

Regarding the location of the current data-dir, it looks like a temporary directory with the prefix gcd is being created and passed as the argument value for --data-dir=. I'm not sure what platform you are developing on, but for me -- on linux -- I would get a directory that looks like this: /tmp/gcd3249584903177434025.

Hope this helps a little for the interim.

[aschroder]

I'd like to add my support to this request :)

Couple of ideas to achieve it:

• make the LocalDatastoreHelper handle configurable start up params
• make it subclass-able so that subclasses can manipulate the emulatorRunners

If you're open to either change, I'm happy to PR it.

[BenWhitehead]

Hi @aschroder Thanks for volunteering to help out!

I think adding the ability to provide some more config parameters would probably be a better path in the long run. I don't think we want to go the route of subclassing for config changes since that creates challenges down the road.

I'm envisioning the following changes here:

1. Create a new class com.google.cloud.datastore.testing.LocalDatastoreHelper.Builder
2. Add each of the existing parameters to the new builder
3. Add new parameters for data-dir etc to the builder
4. Move the current default values from the constructor into the new builder
5. Refactor existing create methods to use the new builder
6. Add a new builder() factory method to LocalDatastoreHelper

This should keep compatibility of the existing API, and keep the existing behavior, while exposing the builder for those folks that want more fine-grained control.

What do you think? Does this sound like something you have time to tackle?