Skip to content
This repository has been archived by the owner on Nov 9, 2022. It is now read-only.

Reusing existing content db (or other db's?) #245

Closed
grtjn opened this issue May 19, 2014 · 8 comments
Closed

Reusing existing content db (or other db's?) #245

grtjn opened this issue May 19, 2014 · 8 comments

Comments

@grtjn
Copy link
Contributor

grtjn commented May 19, 2014

If you point from two Roxy project to a shared content db, both will try to create, update, and delete that content db. You can trick one project by added a custom property, for instance shared-content-db, point to that in ml-config.xml for the http-server settings, and remove the content-db part entirely, but a small flag alike install-xcc=false might be more convenient..

One might also have a good reason to want to share a modules-db. A similar thing would account there. How about some extra flags:

  • install-modules-db=false
  • install-content-db=false

Maybe more?

@grtjn
Copy link
Contributor Author

grtjn commented May 19, 2014

Hmm, slight rectification. The shared-content-db approach only works with install-xcc=false, and maybe a few other command/settings also rely on content-db being present. Perhaps better to keep using content-db setting, but do remove the entire content-db settings part from ml-config.xml. That should prevent it from being included in bootstrap and wipe.

@grtjn
Copy link
Contributor Author

grtjn commented Jun 19, 2014

A slightly different approach could be something like this:

  • shared-databases=${content-db},${extra-db}
  • shared-servers=..
  • shared-users=..
  • shared-roles=..
  • etc

@hutchkintoot
Copy link

+1 being able to do this would be really useful.

@grtjn
Copy link
Contributor Author

grtjn commented Feb 26, 2015

Yet slightly different approach would be to add a shared="true" parameter inside ml-config.xml. It would make it get created at bootstrap (only if missing), and skipped on wipe. An extra param --wipe-shared would force wiping shared stuff..

@grtjn
Copy link
Contributor Author

grtjn commented Jul 12, 2016

You can already get there partly, by specifying a content-db name that already exists, and then removing database + assignments for that database from ml-config. It won't get created, won't get wiped. It must exist upfront..

@dmcassel
Copy link
Collaborator

Would it be sufficient to document the "removing the database assignments" approach, perhaps on the Database Configuration wiki?

@grtjn
Copy link
Contributor Author

grtjn commented Jul 12, 2016

I like the idea of having that shared=true flag in ml-config. It sounds versatile, and should be relatively easy to implement. But a section on that wiki sounds like a good idea too, and perhaps quickest to provide..

@grtjn
Copy link
Contributor Author

grtjn commented Jun 13, 2017

Looking back over this and related tickets my current thinking is not in favor of having configs or flags that tell Roxy something is shared. The reason is that I think it would be confusing if the content-db section is still within ml-config, despite it not doing much, or maybe nothing at all. A shared=true flag can be overlooked easily, but if the content-db section is completely removed, no confusion about whether that project creates/configures the db or not..

I opened this wiki to document the approach in more detail: https://github.com/marklogic/roxy/wiki/Using-an-existing-Content-Database

Same principle should also work for the other db's..

@grtjn grtjn closed this as completed Jun 13, 2017
@grtjn grtjn self-assigned this Jun 13, 2017
@grtjn grtjn added this to the July 2017 milestone Jun 13, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants