Customize gcloudCommand of LocalDatastoreHelper

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

@vtnlinh95

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.

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.

@aschroder

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:

Create a new class com.google.cloud.datastore.testing.LocalDatastoreHelper.Builder
Add each of the existing parameters to the new builder
Add new parameters for data-dir etc to the builder
Move the current default values from the constructor into the new builder
Refactor existing create methods to use the new builder
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?

Navigation Menu

Repository navigation

Customize gcloudCommand of LocalDatastoreHelper #19

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Customize gcloudCommand of LocalDatastoreHelper #19

Description

Activity

BenWhitehead commented on Oct 25, 2019

aschroder commented on Mar 11, 2020

BenWhitehead commented on Mar 12, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions