> There is currently no limit to the number of projects in a system > (besides storage and memory, of course). BaseX databases can point > anywhere they need to in the file system, so there's no reason for > the database files themselves to live in different child folders. > > For example, on our Ubuntu server the databases are written to > /opt/basex/data, while the files the databases represent live in > /home/[user]/public_html/repos/[various children]/files. When we > create new repositories, we put the files in a new folder and create > the BaseX database like: CREATE DB new_name > /home/[user]/public_html/repos/new_repo/files. We haven't used BaseX > in more than one project yet, but if we did we'd just make more > databases pointing at directories under a new /home/[user].
I think this explanation misses the point of my earlier one. If I have a project located at /srv/proj/foo, then make a copy to /srv/proj/bar, I would wish to have two independent copies of the same database data. If I then perform operations on the original copy, I would wish the new copy to retain the same project state from the time of the copy. The new copy of the project should change state only at some time of performing operations on that copy. In this sense, opening a database from a file path is the same as opening an image or text document. Operations of the open file affect the open file, independent of past or future copies, and of other files on the system. In your model, all copies of my project would access the same database, on the same system. Further, when moved to a new system, a project copy would lose all the data from the database. > The only reason I can think of that storing the BaseX database files > in different subfolders might be handy is if you need each of the > sub-projects to be portable, but IME trying to copy BaseX database > files into a new system doesn't work well. It's better to get all of > your scripts in place for creating the databases, and just re-run > them when the project is ready in its new home. It seems not to work well for BaseX, but I am suggesting the limitation is currently coming from the design of BaseX. The request is to generalize the design for full support of embedded databases. Many embedded databases follow a design compatible with my use case. The files of each particular database may be given by a user path, and these files may be copied, resulting in a new independent and working copy of the database, given at the target path for the copy.
