Translating for developers

Hi, what follows are my personal thoughts after reading Dmitry Yemanov's comments to a great poll posted at Firebirdnews about the features people would like to see implemented.

Quote:

1. SMP support is a clear winner (23% of votes) in the poll. And this is definitely one of the high priority tasks in the project. As you know, it was the major goal of the Vulcan development and its implementation is being currently tested. The public test versions will be available soon for those who's willing to test it in real-world scenarios. The final SMP implementation is targeted for the v3.0 release, as stated in our roadmap.

Well, since Intel and AMD are massively going for multicore architectures on the desktop and SMP servers are more and more common in datacenters I wouldn't place this in a whishlist, it's simply a must to stay current, no choice.

Quote:

2. Better security (16%). It's not very clear what security issues are assumed here, but some fixes and improvements are already made and more ones are scheduled for the near future. In particular, you may expect embedded security, database encryption and trusted authentication quite soon.

Again, where are those developers hiding? It's good to see embedded security, database encryption and trusted auth, but isn't it time to add SSL encrypted communications between client and server? And, speaking of SSL, why not adding certificate based auth?
MySQL and PostgreSQL do support this from some time.

Quote:

3. Cross-database queries (14%). This is a quite important feature that requires serious design investigation. Its implementation is not trivial, so it's not in the nearest schedule and hence it may require sponsorship to get a higher priority.

Ahhh, finally, the database is not a single, isolated, ivory tower!!! Now, why not putting up a temptative implementation much like MySQL's Federated storage engine? Something like a simple interface to a client library that dispatches calls to remote databases, which connection parameters are embedded in a view definition, I agree that it's not a clean implementation, but it could be a starter and raise people's attention.

Quote:

4. Faster wire protocol (13%). Some improvements have already been made in this area (see previous blog records) and others are scheduled for the next versions.

Again, is it so hard to add what many other databases already have? Besides improvements to the protocol, which are extemely important for Firebird, please add zlib based compression, it shouldn't be that hard and it will put Firebird on pair with other OSS databases.

Quote:

5. Server monitoring (8%). This feature is already being debugged and tested, so you may expect the core monitoring abilities quite soon.

Great!!! Now, please state it clear, can we hope in a v$sessions like view?

Apart from some sarchasm, I consider Firebird an excellent database developed by a highly motivated and competent group, but I was very surprised reading that post, because it seemed quite surprised by those requests, which are IMHO pretty standard.
Ok, enough for the rants now, have a nice day ;-)

Note: Mariuz (see post comments) added this rant to Firebirdnews and we can read some of Dmitry's comments about it, my favourite is that, yes v$session like views ARE coming!!!

Relocating MySQL data

After an interesting question I'm posting here a simple description of how to place your MySQL data on another drive, if you got a server with multiple disks this can really benefit performance.
The picture is this, you have installed MySQL server in the usual C:\Program Files\MySQL\MySQL Server 5.0\ folder, but you have another drive D: and you want to place your data there, you'll create three folders there:

D:\MySQL DataDir\ which will contain MyISAM tables (.frm, .MYD, .MYI files) and also InnoDB tables definitions (.frm files)

D:\MySQL InnoDBDatafiles\ which will contain InnoDB data (ibdata1 etc. files)

D:\MySQL InnoDBLogfiles\ which will contain InnoDB logs (ib_logfile0, ib_logfile1 etc.)

this will be accomplished by:

1. creating those folders
2. stopping the server
3. editing my.ini file this way:

#Path to the database root
datadir="D:/MySQL DataDir/"

#*** INNODB Specific options ***
innodb_data_home_dir="D:/MySQL InnoDBDatafiles/"

innodb_log_group_home_dir="D:/MySQL InnoDBLogfiles/"

leave unchanged the following line

#Path to installation directory. All paths are usually resolved relative to this.
basedir="C:/Programmi/MySQL/MySQL Server 5.0/"

because you are not relocating the binaries.

4. restart the server.

Note that you .pid and your .err files will also be in D:\MySQL DataDir

Hope this helps!

Note: as you can see from the forum thread linked above, the most common problem is due to the user under which mysql is running not having proper permissions on the target folders.