Changing database location is simple – just launch dump on source database server, import it into destination database, redirect domain and voila! You can use this method to migrate your database into newer database engine version. But what can you do if you realize whole backend must be changed (i.e. from MySQL to PostgreSQL)?
Migrating SQL dump to different database dialect is not very easy (column types / dates formats as first examples come to mind). But you don’t have to operate on SQL dumps. The simple answer here is: “dumpdata”.
(more…)
You probably already know that Subversion stores some kind of metadata for all files added to repository. It’s called “properties” in Subversion vocabulary. This key-value map is responsible for registering ingored files masks, file attributes, internal file content type etc.
The property I’m going to present today is “mime-type“. It describes file content in similar way to HTTP header “Content-type” telling svn client how to handle the file. Typical values are: “text/plain”, “application/octet-stream”. Especially first part of mime-type is important:
- text/*: line-by-line merges are used, diffs are generated
- any other prefix: no text merges prepared
If you do not set this properly right you may end up with messed binary file (end-of-line conversions) or non-mergable changes in text file (that is marked as binary by mistake).
Of course during adding a file to workspace one can forget to set those properties correctly. Here auto-props comes with help. Auto-props are applied when “svn add” command (from command line or from GUI) is issued. Configuration is placed inside “~/.subversion/config” file. Here’s my config fragment from one of projects.
[auto-props]
*.csv = svn:mime-type=text/plain
*.java = svn:mime-type=text/plain
*.sql = svn:mime-type=text/plain
*.sql = svn:keywords=Author Date Id Revision URL
*.jar = svn:mime-type=application/octet-stream
Besides mime-type svn:keywords is being set in the example. It controls which keywords are expanded in source files.
In order to use modern Linux distributions you don’t have to look at console window. All important system properties are configurable by GUI tools. There are times, however, a small bit of scripting becomes very useful. In order to easilly connect GUI and console world you have to pass data between. A small tool: xclip helps in this task.
It’s very easy to install the tool under Debian-based systems:
apt-get install xclip
Collect huge selection into a file (if pasting into terminal may be very slow):
xclip -o > file_name.txt
Download selected URL into /tmp/file.out:
URL=`xclip -o`; test -z "$URL" || wget -O /tmp/file.out "$URL"
Place file contents into clipboard:
xclip -i < file_path
As you can see xclip is a handy tool built with unix-style elegance in mind. Many other applications could be discovered for this tool.
WebSphere uses SQL databases for internal managment of MQ queues (Derby database engine under the covers). Sometimes you need to reset their state. Here’s the script that erase and recreate BPEDB database state (tested under WS 6.1.2):
rm -rf $WID_HOME/pf/wps/databases/BPEDB
echo "CONNECT 'jdbc:derby:$WID_HOME/pf/wps/databases/BPEDB;create=true' AS BPEDB;"|\
$WID_HOME/runtimes/bi_v61/derby/bin/embedded/ij.sh /dev/stdin
Second level cache in Hibernate allows to greatly speed-up your application by minimizing number of SQL queries issued and serving some results from in-memory cache (with optional disk storage or distributed cache). You have option to plug in different cache libraries (or to Bring Your Own Cache – an approach popular among my colleagues from India 
). There are caching limits you must be aware of when implementing 2nd level cache.
(more…)
