Short story: I started learning Django few years ago and created my first django website using mysql database. Over time I realized how much more powerful Postgresql is. And yesterday I decided to migrate my website from mysql to posgresql. But the main question - how?
First google search gave me suggestion - dump mysql database, then convert it to posgresql compatible format using some scripts. Check this page if you're interested.
I started doing it, but there were always some errors, even after conversion. For example, this:
ERROR: column "blabla" is of type boolean but expression is of type integer
I'm continuing my ionic series. Today let's talk about the following scenario:
Scenario: You have two web-apps: one for desktops and another (ionic) for mobiles. Both of them can send email notifications with some link, for example to verify email. Desktop and ionic urls are slightly different, but convertable from one to another. You always receive a desktop version of link to your email.
Task: When user clicks on that link from android device, we need to be able to open it in ionic app. In addition to that, ionic app should be able to parse that link and redirect to proper view.
Today I will start my short series of posts about ionic, mobile framework for Android and iOS. Don't ask me how is it related to Python. I just needed to do some work for mobile.
One common task, that you need to do with ionic is to build your platform and install plugins. Let's choose Android as our platform.
To build android platform and install plugins you need to run commands like this:
Theoretically it should be run once a day. But in practice, every time when I was trying to run "python manage.py runcrons", do_some_task() had been called.
I tried everything, including downgrading django-cron. But the actual problem was that do_some_task had an exception in it. Unfortunately it was not reported in any way. No logs, no warnings were spit by django-cron.
The conclusion
If there is any exception in your job, it will be re-run unlimited number of times by django-cron, ignoring your schedule. Beware of that.
Sometimes it's necessary to install newer version of java that there is in official Debian Jessie repository. In that case you need to download it from oracle website, extract files and update links to java executables. It can be done via update-alternatives or simply by replacing links (which is not recommended). Below I will show you both methods.
1) Update-alternatives way
1) create install folder and navigate to it:
mkdir ~/install
cd ~/install
2) download jdk 1.8. The tricky part here is that you need to accept license agreement by passing a cookie:
4) Install alternative for each java executable that you need to use. In this example we will install 3 alternatives for: java, javac, jar (but you may also install more than just 3):
The last number in the command is the priority which is used in auto-mode only, where program with the highest priority is used as default. If you want to understand the difference between manual and auto modes, I recommend watching this video.
After running each command, change the selection by entering a number, which is manual mode of particular executable in jdk1.8.
2) Manual way (not recommended)
2.1) jdk 1.8
1) Download jdk and extract files as described in 1.1-1.3.
2) update links to point to java 1.8 (you may need to backup original files):
sudo ln -sf ~/install/jdk1.8.0_73/bin/jar /usr/bin/jar
sudo ln -sf ~/install/jdk1.8.0_73/bin/javac /usr/bin/javac
sudo ln -sf ~/install/jdk1.8.0_73/bin/java /usr/bin/java
#sometimes you may need to update default-java
sudo mkdir -p /usr/lib/jvm
sudo rm /usr/lib/jvm/default-java
sudo ln -s ~/install/jdk1.8.0_73/bin/java /usr/lib/jvm/default-java
2.2) jre 1.8
If you don't need java compilers, then you can only download jre.
1) Download jre and extract files as described in 1.1-1.3.
2) update links to point to java 1.8 (you may need to backup original files):
sudo ln -sf ~/install/jre1.8.0_73/bin/java /usr/bin/java
#sometimes you may need to update default-java
sudo mkdir -p /usr/lib/jvm
sudo rm /usr/lib/jvm/default-java
sudo ln -s ~/install/jre1.8.0_73/bin/java /usr/lib/jvm/default-java
The end
That's it. After completing these steps using either 1st or 2nd method you should have working java 8 on your Debian Jessie machine. To check current java version use this command:
java -version
which should return something like this:
java version "1.8.0_73"
Java(TM) SE Runtime Environment (build 1.8.0_73-b02)
Java HotSpot(TM) 64-Bit Server VM (build 25.73-b02, mixed mode)
Today I won't tell you much about Python, but I will tell you about what I've done a while ago using Python. I've been hard at work (mostly at nights and in my spare time) developing my new service, called RuDividends which helps investors across the world analyze dividend stocks in Russia.
The website lists Russian stocks sorted by highest dividend yield. Also you can find all of the dividend history of any stock in one place both in Russian and English languages.
Why did I decide to create this service? First of all, I'm from Russia. Then when I tried to find any good website with all dividend stocks, I could barely find it in Russian and nothing in English. And more important, I created it for my own use, because I invest some funds in Russian companies and I need to analyze dividends anyway.
I also believe that Russia has huge amount of natural resources and most of its companies are undervalued. Some of the companies are paying very high dividends (risk is also high though). Moreover, this year (2016) Medvedev signed an order mandating 8 state-controlled companies to pay at least 50% of their profits in dividends, which helps to plug a hole in the state budget.
All of this shows that you can benefit by investing in Russian companies. Hope you'll find this service useful. And I'd really appreciate if you could spread the word to as many other investors as possible.
pg_dump: server version: 9.4.7; pg_dump version: 9.2.15
pg_dump: aborting because of server version mismatch
Then it means that the version on your local pg_dump tool is older that the version of the remote postgresql database.
In my case I had postgresql 9.2 running on CentOS 7 and I was trying to dump database out of remote postgresql 9.4. So the solution was to install 9.4 using postgresql repository instead of centos distro repository. Below you will find instructions that you need to do in order to fix this issue on CentOS.
1. Navigate to this link and choose necessary rpm:
http://yum.postgresql.org/repopackages.php#pg94
