how to specify postmodern as a database backend

[Davidbhodge]

My project will use postgres as a database and hence postmodern.

I have followed the tutorial ( and would like to submit some suggestions on how to improve it) but would like to start with this issue first

How do I best specify postmodern as the implementation database. Do i use defaulted-config or something else and most importantly what are the path names. Seeing an example of this would be very helpful, as the documentation is a bit sketchy and repl experimentation has me creating entries config directory which seem to have no effect.

And while we are talking about configs, how best to remove r-welcome. I have remconfig'd it, but it still loads through asdf, so wondering where I should look (its not in the project .asd file)

So far i really like what i have seen - you have put in an amazing amount of work on this.

Cheers

[Shinmera]

You need to differentiate between what you do as an application programmer, and what you do as a server maintainer. This is vital, as everything in Radiance is built around maintaining this divide.

Now: if your application does not need the usual extra features offered by a particular database, and instead works just as well with the provided database interface, you should just use that and not worry about which particular database might be used on a deployed installation. It is the job of the server maintainer to pick the database suitable for his installation.

If your application does need more than is provided by the interface, you should instead directly depend on the particular implementation of the interface (i-postmodern in this case), or the underlying library (postmodern). Note that this will effectively force anyone using your program to use postgres. If you don't intend on anyone else ever using your stuff however, then that's fine.

As for configuration files, those are stored relative to *environment-root*, or particularly for a module at (mconfig-storage ...). Part 7 of the tutorial talks about configurations briefly in the context of a deployed system. Now, when you use any of the config functions, then they relate to the currently active module. The configuration of interfaces and standard modules is set through the radiance module. As such, in order to change its configuration from the REPL, you need to either use config while in the radiance package, or use mconfig and explicitly specify :radiance-core instead.

Note that you can use describe-module to see the configuration and properties of a module. So, say (describe-module :radiance T) (you might need to update to get it to work, I discovered a small bitrot bug just now).

In short: which database you pick should not be part of your application, if possible. In order to change which database you use on your particular installation, use (setf (mconfig :radiance :interfaces :database) ...) or change the configuration file manually at (mconfig-storage :radiance).

Edit: to get rid of r-welcome, simply: (setf (mconfig :radiance :startup) (remove :r-welcome (mconfig :radiance :startup)))

[Davidbhodge]

Hi Nicolas,

Thanks for the response - the first of many I suspect.

And thanks again for your work on Radiance.

To respond to your observations about database component choice - there are philosophical and pragmatic reasons.

As a system designer component choice (such as a database) is often driven by over arching requirements that may not be apparent to outside observers. In this case , a significant chunk of the data model needs to demonstrate a complete audit trail of changes. After considerable research and prototyping I have found the postgres is the best choice - there is a trade off of course between portability and application complexity and I am happy to make that in this case - reduced complexity for no easy portability.

Additionally, Postgres supports a solid data model and I have a fair amount of experience with it. There is a lot I can do in the database to enforce consistency and correctness while keeping application complexity to a minimum. It will be a journey of discovery of course to see how this fits in with Radiances view of data models , from what I can see my models are a superset of radiance , but thats a choice I am making (along with doing this in common lisp on the server side). Its probable I will need to use postmodern directly, but I am not certain about that as yet as that will depend on the performance of certain database views. We will see.

You have given me some clues below which I will try out after I send this email. Could we keep this issue open for a day or so, while I try things out?

Cheers

Nicolas Hafner mailto:notifications@github.com 30 September 2017 at 6:43 PM

You need to differentiate between what you do as an application programmer, and what you do as a server maintainer. This is vital, as everything in Radiance is built around maintaining this divide.

Now: if your application does not need the usual extra features offered by a particular database, and instead works just as well with the provided |database| interface, you should just use that and not worry about which particular database might be used on a deployed installation. It is the job of the server maintainer to pick the database suitable for his installation.

If your application does need more than is provided by the interface, you should instead directly depend on the particular implementation of the interface (|i-postmodern| in this case), or the underlying library (|postmodern|). Note that this will effectively force anyone using your program to use postgres. If you don't intend on anyone else ever using your stuff however, then that's fine.

As for configuration files, those are stored relative to |environment-root| https://shirakumo.github.io/radiance/#RADIANCE-CORE:*ENVIRONMENT-ROOT*, or particularly for a module at |(mconfig-storage ...)|. Part 7 https://github.com/Shirakumo/radiance-tutorial/blob/master/Part%207.md of the tutorial talks about configurations briefly in the context of a deployed system. Now, when you use any of the |config| functions, then they relate to the currently active module. The configuration of interfaces and standard modules is set through the |radiance| module. As such, in order to change its configuration from the REPL, you need to either use |config| while in the |radiance| package, or use |mconfig| and explicitly specify |:radiance-core| instead.

Note that you can use |describe-module| to see the configuration and properties of a module. So, say |(describe-module :radiance T)| (you might need to update to get it to work, I discovered a small bitrot bug just now).

In short: which database you pick should not be part of your application, if possible. In order to change which database you use on your particular installation, use |(setf (mconfig :radiance :interfaces :database) ...)| or change the configuration file manually at |(radiance:mconfig-storage :radiance)|.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Shirakumo/radiance/issues/16#issuecomment-333285796, or mute the thread https://github.com/notifications/unsubscribe-auth/ABjLlvVBwZ6oUCdygHB3lPFzUMmCHc4Eks5sndUDgaJpZM4PpNZr.

[Shinmera]

As mentioned, if you require a specific database for your application, you should not rely on the database interface, and instead query the database "natively". Naturally, on a deployed set up, you'll likely want to load the corresponding database implementation for the interface as well, as other components in the system might need access to a database of some kind, and splitting the data over multiple databases is usually not what one desires.

[Davidbhodge]

This application will have , most probably, a single database instance with separate schemas for each customer.

I am fortunate in that the overall load on the system is quite low - but the transaction value is quite high, this gives me room to do things i would not normally do.

Nicolas Hafner mailto:notifications@github.com 1 October 2017 at 10:00 AM

As mentioned, if you require a specific database for your application, you should not rely on the database interface, and instead query the database "natively". Naturally, on a deployed set up, you'll likely want to load the corresponding database implementation for the interface as well, as other components in the system might need access to a database of some kind, and splitting the data over multiple databases is usually not what one desires.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Shirakumo/radiance/issues/16#issuecomment-333335668, or mute the thread https://github.com/notifications/unsubscribe-auth/ABjLlrbIzqJ7TcOxlzBSzo2lZPrVn7Rxks5snqvlgaJpZM4PpNZr.

[Davidbhodge]

Hi there,

Closing this issue

Thanks for your help