09 Nov

Modules databases versus the file system

Author: Dave Cassel  |  Category: Software Development

When you point a MarkLogic application server to some source code, that code can either reside on the file system or in a modules database. Here are some reasons why you might pick one of those over the other.

Modules Database

  1. Deploying code is a transactional update — there’s no need to worry that the server will be reading your source files while you’re in the middle of updating them.
  2. Related to #1, if you’re working in a cluster and an application server is present on multiple instances, deploying to a modules database that spans those instances will let the application server on all instances update to the new code at the same time.
  3. When you’re migrating an application from one server to another, you can use XQSync to move the source code as well as the data.
  4. Using a modules database is actually required for CPF. In a database where you set up content processing, check the Configure tab for the domain — the evaluation context has to be a database.

File System

  1. When you make a change in your code, there’s no deploy step. Just hit save and then refresh your browser (or however you are accessing results). Very simple.
  2. You’ve got your code in a version control system like SVN or GIT (right?), and those expect to live on the file system. I guess you could set up WebDAV and do an “svn checkout …” right into a modules database, but that feels a little weird to me. Your code probably lives in a file system directory somewhere, and you interact with the version control system from there.
  3. When deploying to an integration or production server, I’ve sometimes pointed the application server to a soft link, then update the soft link on the file system after setting up a directory with the new code. I think that addresses point #1 under Module Databases, but not #2 unless you do it on a volume that is visible to all instances.

What Do I Do?

Common practice among my colleagues seems to be use the file system while developing on your local box, then deploy to a modules database for integration or production servers. I’ve actually been using a modules database even for local work lately, because I’ve got an ant script that makes it simple and fast. Even with that, every now and then I forget to deploy.

Where does your code live? Any reasons I haven’t covered?

Tags: ,

3 Responses to “Modules databases versus the file system”

  1. Geert Says:
    November 9th, 2011 at 9:06 am

    You could apply security to code in the modules database. That is not possible when the code is on the file-system. But I admit I have one app server mounted on file-system in which I gather most of my smaller scale development..

  2. SM Says:
    December 10th, 2021 at 10:14 am

    Can share your ant script

  3. Dave Cassel Says:
    December 11th, 2021 at 9:06 am

    There’s no ant script; I use ml-gradle to deploy code. BTW, I did a quick re-read of this post. As a quick update, I never use the file system anymore. It’s really easy to deploy to the modules database locally.

Leave a Reply