Re: [basex-talk] feature request: opening database at arbitrary file path
On Tue, 2022-02-22 at 23:10 +0100, Christian Grün wrote:
The other contributor's comments were deeply rooted in particular assumptions that stood in stark contrast to the scenario I had described.
It always depends on the way you interpret others’ comments. But we're getting circular again (there must be a reason for it ;).
To me, "embedded" and "standalone" carry the same implication in the context of a database
I see. With standalone, we want to indicate that the application stands “on its own” and needs no external accessors. In contrast, something that's embedded is fully dependant on other applications.
In other words, if we use BaseX embedded, we import it as Java library. If we use it as standalone processor, we access it externally, similar to other installed applications and along with all their idiosyncrasies.
Would Java be an option for you?
I understand the distinction. It seems the issues I originally raised would be the same in both cases. The difference is whether the application would be built as a collection of scripts versus a full Java application. I had planned to begin with Bash scripts calling the command-line database application, and then migrate to a more integrated application model (e.g. Java application using a library) only if required by the evolving needs. Frankly, I would hope to avoid the latter for the foreseeable future, as both the overall application complexity and maintenance resources are rather limited. However, as I explained, the overriding concern is whether the databases may be maintained inside of projects' folders without any dependency on resources elsewhere on the file system.
I understand the distinction. It seems the issues I originally raised would be the same in both cases. The difference is whether the application would be built as a collection of scripts versus a full Java application.
As I tried to explain, no configuration files will be written to disk if BaseX is invoked via Java as described. I understood that's one of the side effects you wanted to circumvent?
On Wed, 2022-02-23 at 00:22 +0100, Christian Grün wrote:
I understand the distinction. It seems the issues I originally raised would be the same in both cases. The difference is whether the application would be built as a collection of scripts versus a full Java application.
As I tried to explain, no configuration files will be written to disk if BaseX is invoked via Java as described. I understood that's one of the side effects you wanted to circumvent?
I do want to avoid writing (or reading) configuration files. Are you explaining that these files would be accessed by the standalone application that is packaged with the distribution, but their use may be avoided by accessing the database directly through the library layer from a custom application?
Quoting my previous reply:
For example, you can prevent BaseX from reading the configuration from disk [1].
And one more quote (as I’m not sure it has been fully understood):
In other words, if we use BaseX embedded, we import it as Java library. If we use it as standalone processor, we access it externally, similar to other installed applications and along with all their idiosyncrasies.
If you call BaseX as an external and independent application via scripting, you can't expect it to behave like an embedded library. Eric Levy <contact@ericlevy.name> schrieb am Mi., 23. Feb. 2022, 00:43:
On Wed, 2022-02-23 at 00:22 +0100, Christian Grün wrote:
I understand the distinction. It seems the issues I originally raised would be the same in both cases. The difference is whether the application would be built as a collection of scripts versus a full Java application.
As I tried to explain, no configuration files will be written to disk if BaseX is invoked via Java as described. I understood that's one of the side effects you wanted to circumvent?
I do want to avoid writing (or reading) configuration files.
Are you explaining that these files would be accessed by the standalone application that is packaged with the distribution, but their use may be avoided by accessing the database directly through the library layer from a custom application?
On Wed, 2022-02-23 at 00:56 +0100, Christian Grün wrote:
Quoting my previous reply:
For example, you can prevent BaseX from reading the configuration from disk [1].
And one more quote (as I’m not sure it has been fully understood):
In other words, if we use BaseX embedded, we import it as Java library. If we use it as standalone processor, we access it externally, similar to other installed applications and along with all their idiosyncrasies.
If you call BaseX as an external and independent application via scripting, you can't expect it to behave like an embedded library.
Thank you for reiterating the previous points, to help me see how they converge. I understand the behavior of using configuration files may be disabled through the library call, but is unconditional through the command-line application. The design seems to present a dilemma, as it is unlikely that there would be a viable route for beginning work on a Java application, before a concept is proved through much more lightweight development approaches. Returning to the thought of a feature request, let me suggest that adding switches to the command-line tool, for disabling the behavior mentioned above, and other behavior that may be relevant, or providing a complementary tool targeted at more self-contained deployments, might be a valuable enhancement to the tool chain.
The design seems to present a dilemma, as it is unlikely that there would be a viable route for beginning work on a Java application, before a concept is proved through much more lightweight development approaches.
It depends on you.
Returning to the thought of a feature request, let me suggest that adding switches to the command-line tool
We could add an option for preventing BaseX to read and write the initial configuration file, but we'd then still need to define a home directory in which new databases, users, jobs, etc. are stored. How would you handle that? Have you already checked out the Configuration article in our Wiki that has been referenced multiple times in this thread?
On Wed, 2022-02-23 at 23:09 +0100, Christian Grün wrote:
Returning to the thought of a feature request, let me suggest that adding switches to the command-line tool
We could add an option for preventing BaseX to read and write the initial configuration file, but we'd then still need to define a home directory in which new databases, users, jobs, etc. are stored. How would you handle that?
My first thought would be simply to expose to the command line the flag in the constructor you had referenced. The base case for an embedded database has no user model, and supports creation of new databases only through the target path. However, such differences might press the limits of a benign request. If a target path is needed beyond the database itself, then it might be passed on the command line. Alternatively, a special directory layout might be considered which encloses both the database files and the auxiliary configuration files, as peer sub-directories in the same parent, following a static layout utilized only when the application is invoked in some special mode.
Have you already checked out the Configuration article in our Wiki that has been referenced multiple times in this thread?
Yes, but it doesn't mean I understand quite yet how all the parts fit together. Does it seem I missed or misunderstood something?
The base case for an embedded database has no user model, and supports creation of new databases only through the target path. However, such differences might press the limits of a benign request.
If a target path is needed beyond the database itself, then it might be passed on the command line. Alternatively, a special directory layout might be considered […]
In both cases, we’d rebuild the existing solution step by step. And if no such path is specified by the user, we’d need to ensure for all operations in the system that nothing unexpected happens.
Yes, but it doesn't mean I understand quite yet how all the parts fit together. Does it seem I missed or misunderstood something?
I guess so. What other parts of our documentation have you read so far to get a more comprehensive picture?
The base case for an embedded database has no user model, and supports creation of new databases only through the target path. However, such differences might press the limits of a benign request.
If a target path is needed beyond the database itself, then it might be passed on the command line. Alternatively, a special directory layout might be considered […]
In both cases, we’d rebuild the existing solution step by step. And if no such path is specified by the user, we’d need to ensure for all operations in the system that nothing unexpected happens.
Sorry, I don't understand the meaning of the comment.
Yes, but it doesn't mean I understand quite yet how all the parts fit together. Does it seem I missed or misunderstood something?
I guess so. What other parts of our documentation have you read so far to get a more comprehensive picture?
If you want to suggest a reference that is relevant, I would review it, if I have not done so yet. I don't wish to compile a list of documents or sections I have already reviewed.
Hello. I never had a chance to gain a full understanding of the direction of this discussion. Had there been any suggestion that some feature enhancement might be considered? I felt the suggestion may have been given, but it was never resolved. On Fri, 2022-02-25 at 02:37 -0500, Eric Levy wrote:
The base case for an embedded database has no user model, and supports creation of new databases only through the target path. However, such differences might press the limits of a benign request.
If a target path is needed beyond the database itself, then it might be passed on the command line. Alternatively, a special directory layout might be considered […]
In both cases, we’d rebuild the existing solution step by step. And if no such path is specified by the user, we’d need to ensure for all operations in the system that nothing unexpected happens.
Sorry, I don't understand the meaning of the comment.
Yes, but it doesn't mean I understand quite yet how all the parts fit together. Does it seem I missed or misunderstood something?
I guess so. What other parts of our documentation have you read so far to get a more comprehensive picture?
If you want to suggest a reference that is relevant, I would review it, if I have not done so yet. I don't wish to compile a list of documents or sections I have already reviewed.
Hi Eric, There had been the suggestion that our documentation will provide you more information on how BaseX works. After you have invested more time on the status quo, we might be able to get some progress on this discussion. Best, Christian On Thu, Mar 3, 2022 at 4:31 PM Eric Levy <contact@ericlevy.name> wrote:
Hello. I never had a chance to gain a full understanding of the direction of this discussion. Had there been any suggestion that some feature enhancement might be considered? I felt the suggestion may have been given, but it was never resolved.
On Fri, 2022-02-25 at 02:37 -0500, Eric Levy wrote:
The base case for an embedded database has no user model, and supports creation of new databases only through the target path. However, such differences might press the limits of a benign request.
If a target path is needed beyond the database itself, then it might be passed on the command line. Alternatively, a special directory layout might be considered […]
In both cases, we’d rebuild the existing solution step by step. And if no such path is specified by the user, we’d need to ensure for all operations in the system that nothing unexpected happens.
Sorry, I don't understand the meaning of the comment.
Yes, but it doesn't mean I understand quite yet how all the parts fit together. Does it seem I missed or misunderstood something?
I guess so. What other parts of our documentation have you read so far to get a more comprehensive picture?
If you want to suggest a reference that is relevant, I would review it, if I have not done so yet. I don't wish to compile a list of documents or sections I have already reviewed.
Eric, I wonder if you are doing something similar to what I am doing. I have a bunch of databases found in directories, and I currently use paths that look a lot like my directories. declare variable $gnt:Nestle1904.tei := doc("macula/GNT/Nestle1904/tei/nestle1904.xml"); declare variable $gnt:Nestle1904.morph := doc("macula/GNT/Nestle1904/morph/Nestle1904.xml"); declare variable $gnt:Nestle1904.lowfat := doc("macula/GNT/Nestle1904/lowfat/nestle1904lowfat.xml"); If I were writing a function that opened databases in a particular directory, I might pass the "current directory" to that function. I suspect that's an application-domain concept, not something that BaseX should model for your application. After all, someone else might have a rather different notion of a working directory for their application. And "working directory" at the database level would add state in a way that would be actively unhelpful for stateless APIs. Jonathan On Thu, Mar 3, 2022 at 10:39 AM Christian Grün <christian.gruen@gmail.com> wrote:
Hi Eric,
There had been the suggestion that our documentation will provide you more information on how BaseX works. After you have invested more time on the status quo, we might be able to get some progress on this discussion.
Best, Christian
On Thu, Mar 3, 2022 at 4:31 PM Eric Levy <contact@ericlevy.name> wrote:
Hello. I never had a chance to gain a full understanding of the direction of this discussion. Had there been any suggestion that some feature enhancement might be considered? I felt the suggestion may have been given, but it was never resolved.
On Fri, 2022-02-25 at 02:37 -0500, Eric Levy wrote:
The base case for an embedded database has no user model, and supports creation of new databases only through the target path. However, such differences might press the limits of a benign request.
If a target path is needed beyond the database itself, then it might be passed on the command line. Alternatively, a special directory layout might be considered […]
In both cases, we’d rebuild the existing solution step by step. And if no such path is specified by the user, we’d need to ensure for all operations in the system that nothing unexpected happens.
Sorry, I don't understand the meaning of the comment.
Yes, but it doesn't mean I understand quite yet how all the parts fit together. Does it seem I missed or misunderstood something?
I guess so. What other parts of our documentation have you read so far to get a more comprehensive picture?
If you want to suggest a reference that is relevant, I would review it, if I have not done so yet. I don't wish to compile a list of documents or sections I have already reviewed.
participants (3)
-
Christian Grün -
Eric Levy -
Jonathan Robie