MyOwnDB Blog

Two new features have been rolled out, both having to do with getting data in and out of MyOwnDB.
We’re very excited about this!

It is now possible to import data from a CSV file through a very simple procedure:

1. upload your CSV file
2. link columns in the CSV file to fields in your database table
3. get an overview of the import: number of rows imported and number of rows rejected

Rows can be rejected due to data validation exceptions, for example:

• trying to import text in an integer field
• trying to import an invalid email address in an email field
• trying to import invalid data in a choice in list field
• …

Soon to come is the ability to undo an import.

To get data out of MyOwnDB, we just rolled out a simple REST API. This is currently limited to listing entries in one table, with filtering options. Actually it uses the same code generating lists in the web UI.

To get to the list of entries in one of your tables, send a GET request to

http://www.myowndb.com/app/rest/simple/v1/instances?id=ENTITY_ID&api_key=API_KEY

where you replace ENTITY_ID by the id you find in the url when looking at the
list of entries.
For example, in this URL:
http://www.myowndb.com/app/entities/list/3770
the ENTITY_ID is 3770.

You can find you API_KEY on your settings page.

It is possible to filter entries returned based on values in 1 column. A
multiple columns filter will be made available in a future version.

Parameters recognised are:

• order_b: column to order by
• detail_filter: column to filter by
• value_filter: value to filter with
• callback: function in which the json will be wrapped (aka JSONP
• starts_with: by default, the filter is comparing the start of the values. If you don’t want this, pass no as value for this parameter
• ends_with: pass yes to filter on the end of the values

We hope you enjoy these additions!

Here are the slides of the talk I gave in the Ruby devroom at FOSDEM 2009.

As usual, FOSDEM was a great place to meet fellow developers. It was was first talk there, and I enjoyed it a lot!

I’ll have the opportunity to give a talk about Dedomenon, MyOwnDB’s engine, at FOSDEM on sunday at 11:15. This will be about the inner workings of Dedomenon and will be technical.

Although our UI has not changed in a long time (but expect some news about that soon), there’s been quite some work being done under the hood, especially in our infrastructure. In the previous weeks we have had literally dozens of deployment happening on our production application.

As we’re possibly deploying multiple times a day, it became important that our users be able to follow these evolutions, if only to be able to include the version number they are talking about when contacting us about the application. And that’s now possible: the header of the application contains a version reference:

Bart got interviewed for Datanews, a major IT magazine un Belgium, and you can see the resulting article online in dutch and in french.
The article doesn’t cover our software, but rather our business and the problem we want to tackle: the publishing of structure information.

I’m not lazy at writing neither I’m bad. But I do not have my personal blog! Because I wont be updating it much!

Developing a REST API on top of MyOwnDB was our prime decision to make it integrate able to a number of products/services. And that way, we want to be the memory of Web 2.0!

We’ve been working with the REST API for sometime now and it was a leap from a concept to its application to MyOwnDB within the Rails framework. We had to make many interesting design decisions and for that, I explored top ten REST API’s available including Twiter, Google, Flicker and many more. I gathered their conventions, practices and the way they’re dealing with some of the situations which do occur while you’re exposing some functionality as a web service (of course specifically based on REST paradigm).

First and foremost decision that we made was: REST API wont be into the core application. It would be an optional plugin. And in order to do that, We had to switch to engines plug-in. Don’t know why, but I’m not happy whenever adding an external dependency such as a plugin to the application. So was the case with engines.

Today I was browsing the commit history of rails master branch on github while I discovered a commit by DHH himself which indicated that from Rails 2.2, any plugin that contains an app directory would be added to load path. What does this means? Simply now you can place controllers, models and views in a plugin! No engines plugin needed! Not only that, but adding routes from teh engines plugin was not pretty much straight forward and it required few lines of code into your environment.rb and not only that, but your route.rb should be on root of your plugin and it mentions/draws the routes in a little bit different mannor then you’d be doing in your Rails application.

But the news is that these days are gone too! Because from Rails 2.2, if a plugin contains a file config/routes.rb, then those routes would be added to the RouteSet because draw method does not clear out all the routes rather its additive in nature now. So in affect, engines plugin would not be needed for MyOwnDB for our REST API plugin to work.

There are some other changes which were interesting to know regarding Rails 2.2 specially that your application.rb file is now called application_controller.rb and its a breaking change in that if you’re upgrading to Rails 2.2, you’d have to rename your application.rb to application_controller.rb

I had a chance to write a small client in Java that reads data from MyOwnDB through our REST API. More on that later! ;-)

Best regards,
Mohsin Hijazee

The talk at T-Dose when well, and gave an interesting discussion about the possible use of Mysql to power a Dedomenon installation, which came down to the need of an equivalent of tablefunc module with its crosstab function for mysql to make it happen.
Here are the slides, in pdf format.

On saturday 25 october, Raphaël will give a talk on Dedomenon, the engine powering MyOwnDB.com, at T-Dose.

T-Dose being a event focused on open source technologies, the talk will focus on Dedomenon, our engine available under the AGPLv3 license at dedomenon.org. If you want to learn how Dedomenon is structured, how you can adapt it, this is the talk to attend.

A some of you may know, Raphaël is also the founder of FOSDEM, and it will be a lot of fun for us to be at the other side (the speaker side, that is) this time! Hoping to see a lot of you there!

We were looking at the engines plugin for a while and despite all the flame wars around it, Me and Raphael were somewhat convinced that it would be needed somehow in future.

I kept trying installing it but failed. So a little context here, we ported our application from Rails 1.2 to Rails 2.02. And it was this version which we “freezed” under the vendor directory. And installing engines plugin on that version was failing.

From my past development experiences, and from observing some colleagues for a while in my career, I’ve a nature of being very lean and mean about things. If something simpler gets the job done, I’ll not think about intellectually appealing solutions even if they offer more. So this nature kept me from trying to install engines plugin as though it was needed but it was not blocking our way so far. So in my view, I kept making progress on other things.

For last two days, I was working to make it possible to extend with more data types then available by default. For this, we had a vision of using plugins. I again thought about engines plugin and failed. As I said earlier, it was not blocking so I moved on. But this evening, Raphael was working with engines and he told me that he has them up and running! I was really happy to know this as this meant a whole lot new range of possibilities!

So here I’ll outline the steps that Raphael did in order to install the rails plugin:

First of all, Its better that you move to Rails 2.1.0 and not only that, also freeze your application to this version.
You need to install rails if its not already the case:

$ gem install rails # So that you have latest version installed.

Next from root of your application, You need to unfreeze your previous version of rails if any:

$ rake rails:unfreeze # Remove previously frozen version if any.

Next you need to freeze the version of rails from your gems into your application:

$ rake rails:freeze:gems # Will freeze rails application under vendor/rails

Also, you need to update the scripts of rails. This is needed because this updates the plugin script which in turn enables you to install plugins from git repositories. And its somewhat mandatory to do this for installing engines plugin!

$ rake rails:update:scripts # Would update scripts

So far you are done with updating rails and freezing it under vendor/rails. I’d recommend that you run your tests rigorously after this to be sure everything is fine.

So next step is that of installing engines plugin. So that’s simple:

$ ruby script/plugin install git://github.com/lazyatom/engines.git

Next you need to alter your config/environment.rb a little bit so that engines plugin is able to modify the core of Rails. For that, Add following line just before the require statement of Rails itsef:

require File.join(File.dirname(__FILE__), '../vendor/plugins/engines/boot')

And you are good to go! I’d say again run the tests to check if all working well. And if so, Congratulations!
I promised to write about Globalite further, short on schedule, so that’s for some other time!

Regards,
Mohsin Hijazee

Hello World!

Well its not the usual hello world program but some blog entries might also start with this phrase! And if in doubt, this entry is the proof!

We are working on MyOwnDB that’s obvious! But title says YourOwnDB? No we are not renaming it at all, rather its to convey that if it is in your own lingo, its more yours!

So actually I’m talking about the localization. I’d not rephrase all about the importance of localization of software especially if its the one like MyOwnDB.

When we started with MyOwnDB, it was Rails 1.2 and there was no suitable localization solution around. So in order to get the job done, we started out on our own and we wrote a plugin for us. The plugin was nice, we could localize, even it was crafted to be dual ended enabling translators to add more languages for the interface if any.

But it was heavy. It had its own database to hold languages, translations and others. And this means another database have to be taken care of in deployments, releases and all the matters!

When we ported the application to Rails 2.02, many good localization solutions were on the scene. After a little discussion and evaluation between me and Raphael, we agreed to pick Globalite as our choice. The transition was quite smooth. We wrote a ruby script that dumped our database containing UI translations to YAML format expected by Globalite, wrote a simple wrapper method around the Globalite translation method in order to reduce the transition cost involved and all started working fine!

Next was making it possible to switch UI language from the interface, so that was also simple and we were easily able to do that.

So in a nutshell, Its simple to localize MyOwnDB in your language and if you want to see it in your own language, please let us know.

Well how exactly we did that, that’s a matter which needs little recalling and not only that, I leave it for a separate blog entry!

Regards,

Mohsin Hijazee