How do I specify the path to my SQLite database in Slick? - scala

I'm trying the Play framework with Scala and Slick for data access.
I'm playing with the play-scala-intro example app. I'm trying to set up my own database instead of using the bundled in memory H2 database.
I can't figure out how to specify the path to the database file.
If the code in application.conf reads:
slick.dbs.default.db.url="jdbc:sqlite:/test.db"
slick.dbs.default.db.driver="org.sqlite.JDBC"
where should my test.db file be placed?
Does that mean the test.db file should be in the home directory of the web app, meaning the root play-scala-intro dir, or the app/assets dir?

I'd say storing your database in Java resources (and that's where assets will end up) doesn't sound like a good idea to me. I would be surprised if nothing went wrong during e.g. writing to DB.
It would be better to have it in the same directory as JAR, and even better set some defaults and let them be overridden:
database.location="test.db"
database.location=${?DBLOCATION}
slick.dbs.default.db.url="jdbc:sqlite:"${database.location}
This should assume that your database is names test.db and placed in your working directory (see: https://stackoverflow.com/a/21061029/1305121). It can be overridden using environment variable DBLOCATION like:
export DBLOCATION="/tmp/my/database.db"
# run Play application

Related

How to add a folder and its content to the standard paths of Playframework and Heroku?

I have a Scala Play framework 2.7.x application which I deploy in Heroku. I use Lucene to index the WebApp and since there is no JdbcDirectory in Lucene I need to use their FSDirectory instead and that leads to issues with Heroku because I can't generate the index files under $APP_HOME/lucene-index/* in Heroku otherwise it will be wiped out each time. This leads me to two possible solutions and this is the simpler one:
Generate the $APP_HOME/lucene-index locally before deployment and save it in GIT, this folder will be at the same level as $APP_HOME/app and $APP_HOME/public.
Integrate the new nonstandard Play folder $APP_HOME/lucene-index so that it gets copied by Heroku (the purpose of this OP).
Upon startup the application checks for this folder and if doesn't exist (local case) gets generated otherwise it opens it (Heroku case).
Do I need to do something special on #2 to have Heroku recognize $APP_HOME/lucene-index/ as a folder that needs to be packaged together with the application? e.g. I would not like to put the $APP_HOME/lucene-index/ under $APP_HOME/conf/ for this to work.
Here I find the Anatomy of a Play 2.7.x application but there is no word on how to add extra path folders to it.
The solution I was after was to include the ./lucene-index folder as part of the Play dist. This is accomplished by changing the build.sbt file adding:
//********************************************************
// Add lucene-index to the dist
//********************************************************
import com.typesafe.sbt.packager.MappingsHelper._
mappings in Universal ++= directory(baseDirectory.value / "lucene-index")
Now it deploys to Heroku and it all works nicely.

Local configuration in deployed Clojure apps

What is the idiomatic way to store and retrieve configuration settings in a deployed Clojure Luminus app?
In the Luminus template on which I base my app, the profiles.clj file is used to store the database connection string. However, when I compile the app using lein uberjar the profiles.clj settings do not seem to be included in the compiled file. And I would nevertheless not want the database connection to be stored in the compiled file but rather reside in a configuration file on the production server.
Optimally, local configurations should be stored and retrieved in the same manner regardless of whether the app is run in development or production mode. But I can't figure out how to do it.
You may be interested in using the environ library. From their README:
Let's say you have an application that requires a database connection. Often you'll need three different databases, one for development, one for testing, and one for production.
Lets pull the database connection details from the key :database-url on the environ.core/env map.
(require '[environ.core :refer [env]])
(def database-url
(env :database-url))
The value of this key can be set in several different ways. The most common way during development is to use a local profiles.clj file in your project directory. This file contained a map that is merged with the standard project.clj file, but can be kept out of version control and reserved for local development options.
{:dev {:env {:database-url "jdbc:postgresql://localhost/dev"}}
:test {:env {:database-url "jdbc:postgresql://localhost/test"}}}
The http://www.luminusweb.net/docs/environment.md#edn_based_configuration page helped me.
java -Dconf=config.edn -jar app.jar will start a compiled app with the configurations stored in config.edn.

How to upload file to PostgreSQL database using flyway?

I use in Windows 7 IntelliJ IDEA 12, JDK 7, MyBatis, Spring 3 in order to create REST web application (Maven project with flyway-maven-plugin). I use Flyway in order to cope with sql migrations. Now I need to load some files to PostgreSQL 9.2 database. I've found this thread: https://dba.stackexchange.com/questions/1742/how-to-insert-file-data-into-a-postgresql-bytea-column
I'd like to use bytea_import from that thread. This custom function requires path to the uploaded file (it is in resources folder). How can I correctly set relative path to such file? What is considered as a current folder during migrations?
Not sure about bytea_import (if you get it working, let me know!), but you should be able to achieve this easily using Java-based migrations.
You can use Java-based migrations. If you still want to use SQL-based migrations, then use Flyway placeholders. Save required path in placeholder using *.pom properties. Example:
<flyway.placeholders.rtfPath>${project.build.outputDirectory}/rtf</flyway.placeholders.rtfPath>
Then use rtfPath in your SQL migration file in order to generate the full path to your uploaded file.

About the folder for scripts

I'm at this part of tutorial for zf1.
It says:
At this point we have a connection to a database; in our case, its a connection to a Sqlite database located inside our application/data/ director..",
And then it shows an sql clause that I should save in a folder called scripts, but... where is that folder?
You can create the folder if it doesn't already exist. Its location is not important as its contents are not used by your application directly, but by convention the folder would sit in the root of your app.
For reference, he's the recommended folder structure for a ZF1 application: http://framework.zend.com/manual/1.12/en/project-structure.project.html - the scripts folder there is the one on line 35. This is an extreme example - your application will likely have a lot less folders than shown in that guide.

packaging and deploying java desktop application with embedded database

I created a simple desktop application that uses embedded database(derby) from netbeans.After adding two entries into the table inside the ide and running it again works perfect.But when i double click the executable jar file outside the ide an empty database is shown what might be the reason? I would also like to know how to make this run on client machine.I tried adding the jar and lib files into a folder and converting it into a rar file but i don't find the jar file after extracting.I am new to this and any help would be appreciated.thanks in advance
There are two common reasons why you find that you are getting an empty database unexpectedly:
You are saying ';create=true' and using a relative database name, meaning that you are giving Derby permission to create the database fresh if it doesn't exist, and then your Derby system home directory is changing from run to run, so you are ending up creating new copies of the database each time, in different current directories.
You are using a different username when you connect to the database. Since the username with which you connect implicitly specifies the schema in which your tables reside, using a different username causes you to see a whole different set of tables, or, depending on how you look at it, an empty database.
Regarding jars and rars and such, the crucial thing is to manage your CLASSPATH properly. You need to have the Derby code in your CLASSPATH at runtime. There are a large variety of ways to make this happen, so you'll need to be quite explicit about the particulars of your situation in order for others to give you much help.