Make db fields public

[virmundi]

I trying to use this library as the basis for an ArangoDB migration tool. Creating a new database is harder than it should be since the DB properties are hidden. I'm sure I could get them with reflect, but I don't think that should be necessary. Would you be open to making the fields for NewDatabase public via an interface or just regular public?

[solher]

When you say creating a new database, you mean creating a new database object right? You can easily switch any parameter at any moment using the Options method, as shown in the documented Basic Usage:

  // We declare the database definition.
  db := arangolite.NewDatabase(
    arangolite.OptEndpoint("http://localhost:8529"),
    arangolite.OptBasicAuth("root", "rootPassword"),
    arangolite.OptDatabaseName("_system"),
  )

  // The Connect method does two things:
  // - Initializes the connection if needed (JWT authentication).
  // - Checks the database connectivity.
  if err := db.Connect(ctx); err != nil {
    log.Fatal(err)
  }

  // We create a new database.
  err := db.Run(ctx, nil, &requests.CreateDatabase{
    Name: "testDB",
    Users: []map[string]interface{}{
      {"username": "root", "passwd": "rootPassword"},
      {"username": "user", "passwd": "password"},
    },
  })
  if err != nil {
    log.Fatal(err)
  }

  // We sign in as the new created user on the new database.
  // We could eventually rerun a "db.Connect()" to confirm the connectivity.
  db.Options(
    arangolite.OptBasicAuth("user", "password"),
    arangolite.OptDatabaseName("testDB"),
  )

What kind of difficulties are you encountering?

[virmundi]

I need to be able to read the database name. Presently I have to manually keep track of the value through the call stack. For example, when creating a migration I first start with _system to see if the database the user specifies is there. If not, I look to see if the first migration step is creating the db. if so I execute that then switch to the new db after creation. All this time I have to hold onto the current db to see if it's _system.

[solher]

Oh ok for read operations good point.

I'm just trying to keep the tiniest API surface possible to be able to refactor easily in case of missing features (and there are probably a lot). For example, if I had publicly exposed the authentication user/password, I would have been blocked when adding the JWT auth support (the credentials are not in the Database object anymore).

Would a getter on the current database name be good enough in your case? Anything else you would like to be able to do?

[virmundi]

I think getting the read operations would help. I'll open another ticket for a feature request on another topic.