Python Matplotlib - showing or hiding a legend in a plot

When working with Matplotlib of visualize your data there are situations that you want to show the legend and in some cases you want to hide the legend. Showing or hiding the legend is very simple, as long as you know how to do it, the below example showcases both showing and hiding the legend from your plot.

The code used in this example uses pandas and matplotlib to plot the data. The full example of this is part of my machine learning example repository on Github where you can find this specific code and more.

Plot with legend
The below image shows the plotted data with a legend. Having a legend is in some cases very good, however in some cases it might be very disturbing to your image. Personally I think keeping a plot very clean (without a legend) is the best way of presenting a plot in many cases.

The code used for this is shown below. As you can see we use legend=True

df.plot(kind='line',x='ds',y='y',ax=ax, legend=True)

Plot without legend
The below image shows the plotted data without a legend. Having a legend is in some cases very good, however in some cases it might be very disturbing to your image. Personally I think keeping a plot very clean (without a legend) is the best way of presenting a plot in many cases.

The code used for this is shown below. As you can see we use legend=False

df.plot(kind='line',x='ds',y='y',ax=ax, legend=False)

MYSQL using numbers in VARCHAR fields

Recently someone asked me to help out with some coding parts for a startup they where beginning. Some of the things they needed help with where infrastructure related and some where more in data management and some query modeling and optimization on an already existing datamodel done in a MySQL database.

This gave me some options to start exploring again some things in MySQL which is not my standard database to develop in and use as I am more focusing on Oracle databases. Part of the fun was trying to find out why some queries where not working as expected, main reason for this was that the person who originally designed the datamodel had a love for the VARCHAR datatype.

In the database we do have a table named ovsocial_inst which holds an ID column named inst_m_id. For some reason the original datamodel developer created the column as a VARCHAR even though it is only holding numbers. Now some funny effects do happen when you try to sort.

When you execute the following query:

SELECT 
      inst_m_id
FROM 
    ovsocial_inst
ORDER BY 
        inst_m_id

you will get a result something like:

inst_m_id
1
10
2
3
4
5
6
7
8
9

This is somehow a little strange as long as you do not realize that the values of inst_m_id are treated as text. When you consider it to be text everything makes sense and the query is doing exactly what you ask it to do. However, we do not want it to behave in this manner, we do want it to treat the numbers as numbers even though they are stored in a VARCHAR column. To do so in a sort we can use the following query which converts the VARCHAR into an unsigned.

SELECT 
      inst_m_id
FROM 
    ovsocial_inst
ORDER BY
        convert(inst_m_id,unsigned) ASC

Now you will get a result as you expect;

inst_m_id
1
2
3
4
5
6
7
8
9
10

Now imagine another scenario. we know that the table ovsocial_inst will be relative small so to assign a new ID to a record we would like to query the table for the max inst_m_id + 1 and we would like to use that value to insert a new record. When you do not consider the fact that the values are written to the table in a VARCHAR manner this process will work until you have 10 records in your table. Reason for this is that if you have 9 records in your table the highest value (the latest in the sort) is 9. This means that the new ID is 10 (9+1). When we hit 10 records something strange will happen. when we hit 10 records the highest value or at least the latest in the sort will be 9. This results in a new ID of 9+1 instead of 10+1.

When your ID field inst_m_id would have been a proper column for holding numbers you would use a query like the one below;

SELECT 
      (max(inst_m_id)+1) as new_id
FROM 
    ovsocial_inst

however, the above will give the issue as soon as you hit more then 10 records. To prevent this you will need to construct your query like the one below;

SELECT 
      max(convert(inst_m_id,unsigned))+1 as new_id
FROM 
    ovsocial_inst

In this way you will ensure that it keeps working even if you hit the 10 marker.

Developing PHP multi database applications.

When developing a website or web enabled solution in PHP most developers do consider the fact that there database might be migrated to a newer version, what most do not consider is that they have to migrate to a completely different database platform. This might sound strange to some as they are developing there application for a specific database platform. However, when you develop a application which can be used at several sites you might not always be able to rely on the same database. Or in cases you are building a opensource or commercial solution you users might not always want to work with the database you have in mind. You might be developing your code on a Oracle 10G database while your customer thinks a Oracle database is overkill and wants to use a MySQL or PostgreSQL database.

For those who are not familiar with the three tier architecture, this architecture is describing the situation where you have a client, application server and a infrastructure server. The client is in a PHP web enabled solution a customer running a web browser, the application server is running a webserver with the PHP engine enabled. The infrastructure server is running a database. In the picture below you will see that all tiers are represented by a different server (or client pc). What you normally will see in not so critical environments is that the applications server and the database server are running on the same hardware platform.

When planning to build a PHP solution you might want to think about this problem and might plan in advance. To prevent that you need to write code for every possible database platform you will need to have a SQL translating engine in the middle. Even SQL is quite a standard language there are quite some differences between the database vendors SQL implementation.

You might consider to write your own SQL translator however there is a good opensource solution which can help you with this problem. ADOdb is a database abstraction library for PHP and will give you support on MySQL, PostgreSQL, Interbase, Firebird, Informix, Oracle, MS SQL, Foxpro, Access, ADO, Sybase, FrontBase, DB2, SAP DB, SQLite, Netezza, LDAP, and generic ODBC, ODBTP. This enables you to write a single code pack to connect to all those “infrastructure” tiers instead of writing code for all those platforms.

Using the solution as shown above will prevent you from having the situation as shown here that you have to develop and maintain a large number of releases. Even do your developers will have to learn to adopt a new way of coding it will in the long run pay of when you decide to migrate to a different database platform or when you are working on a solution you will be distributing to customers. When you are developing