Ozzie.eu

Working on a mixed environment, with Windows and Linux boxes, you might want to share some stuff from a linux machine with a user that doesn’t have an SSH client with file tranfer support or even installed. Or even send some files to download to a non-techie team mate. Something everybody is used to is downloading files from the browser, why not use that?

On your linux box, go to the directory where the files are stored and run the following command:

python -m SimpleHTTPServer

For example, I shared a folder called “vmware-tools-distrib”:

Afterwards, the target user only has to open the browser and navigate to the address of the linux box on port 8000.

Easy and handy.

The guys at Yahoo released their partition management script on github:

At Yahoo, we manage a massive number of MySQL databases spread across multiple data centers.
We have thousands of databases and each database has many partitioned tables. In order to efficiently create and maintain partitions we developed a partition manager which automatically manages these for you with minimal pre configuration.

You can check out the original anoucement at the MySQL@Yahoo blog and the code at its github repo.

Link: Yahoo's MySQL Partition Manager is Open Source

So, I was going through the documentation for SQL Server 2016 Always Encrypted feature and I read this paragraph:

The driver encrypts the data in sensitive columns before passing the data to SQL Server, and automatically rewrites queries so that the semantics to the application are preserved.

We’ll still be able to get the execution plan for the query from the server, but regarding optimization, similar issues to the ones that arise from ORM frameworks might pop-out.

Anyway, going further down the same documentation, you get the feature constraints, like:

• Queries can perform equality comparison on columns encrypted using deterministic encryption, but no other operations
• Indexing columns encrypted using randomized encryption is not supported.
• Query parameters that map to encrypted columns must be passed as driver-level parameters.
  

Also, you have some characteristics that disallow the use of encryption, like:

• Columns that are referenced by statistics
  
• Columns using alias type
  
• Partitioning columns
  
• Columns with default constraints
  

The case is clear that it’s a wonderful

security-wise

feature. Before adopting it on your business driven development, make sure it won’t become a source for technical debt for your current code base and future developments.

Playing around with the Employees sample database and full text search on MySQL, I found a weird bug. After creating a full text targeting a column on a table, a "select distinct" query to retrieve the range of values returns an empty set.
So if you initially perform the following query, the outcome comes with 7 rows:

mysql> select distinct title from titles;
+--------------------+
| title              |
+--------------------+
| Senior Engineer    |
| Staff              |
| Engineer           |
| Senior Staff       |
| Assistant Engineer |
| Technique Leader   |
| Manager            |
+--------------------+
7 rows in set (0.38 sec)

If you create a fulltext index on the titles table, over the title column:

mysql> alter table titles add fulltext index `title` (`title`);
Query OK, 0 rows affected (14.65 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> select distinct title from titles;
Empty set (0.00 sec)

So, apparently our records are gone? Repeat the query, but with COUNT:

mysql> select count(distinct title) from titles;
+-----------------------+
| count(distinct title) |
+-----------------------+
|                     7 |
+-----------------------+
1 row in set (0.24 sec)

The records are not gone, they justo won't appear with the DISTINCT aggregate function. If you drop the FT index, the query returns the correct result set.
If dropping the index is not an option, you can workaround this bug, repeating the query with UCASE:

mysql> select distinct(ucase(title)) from titles;
+--------------------+
| (ucase(title))     |
+--------------------+
| SENIOR ENGINEER    |
| STAFF              |
| ENGINEER           |
| SENIOR STAFF       |
| ASSISTANT ENGINEER |
| TECHNIQUE LEADER   |
| MANAGER            |
+--------------------+
7 rows in set (0.44 sec)

This bug is already reported at MySQL Bugs. It's #79497. It appears to be an upstream issue, reproducible on current 5.6 and 5.7.

Link: MySQL Bug #79497: Full text indexes and aggregate functions

This bug is already reported at MySQL Bugs. It appears to be an upstream issue, reproducible on current 5.6 and 5.7.

Link: Should we be muddying the relational waters? Use cases for MySQL & Mongodb | Scalable Startups

Seems I’m not the only one keeping away from JSON on the relational DB:

I would shy away from the NoSQL add-ons that some relational vendors have added, to compete with their newer database cousins. This starts to feel like a fashion contest after a while.

You can also get my point of view on this matter:

• JSON on MySQL: still not fond of it.
  
• JSON on the database? No thanks!