It was a lonely Valentine’s Day for me this year, so I decided to code a framework to practice my SQL, Java, design patterns and Android skills I gained this year. I came up with the idea that coding a lightweight object relational mapper framework would be exciting! :P Then the hack has began and continued on my spare times. What I was trying to achieve a really small framework so that everyone can use databases in their programs and handle common database usages **without writing SQL **so that all the Java objects are can be saved to and queried from database.

This is not a new idea if you are familiar with the concept already. This is called Object-Relational Mapping and there are hundreds of ORM tools including multi-million dollars projects use such as Entity Framework and Hibernate. As you might guess, those support almost all kinds of databases you might be familiar with and they are really cutting-edge software technologies.

Read article: Why ORMAN is better than other ORMs for you?

Motivation

It might seem so but I was not trying to reinvent the wheel.

Features I wanted to imitate from other ORM tools:

  • Map every entity Java class to database table and every field to database column.

  • Tables will be created automatically using Java classes and their fields.

  • Developer will be able to use database in a few lines of code – without writing SQL!

  • Make things flexible and configurable.

    • Support all common cases a medium-scale application can have.

    • Do not make developer write SQL. If it is really needed, provide a query builder.

    • Handle security vulnerabilities for developer.

However, what I was trying to achieve was different than those enterprise solutions:

  • For dummies (everybody should understand how to use it in 15 minutes)

  • Very small (orman.jar is currently around 155 KB and hibernate-core.jar is around 3.86 MB)

  • No dependencies (except database connector JARs. many other Java ORM solutions have bunch of library dependencies)

  • No boring configurations (many ORM tools are configured through XML files, ORMAN uses Java annotations)

Use cases

I started using databases when I was 15 (true story). I didn’t know about foreign keys, indices, and even I was not aware of database normalization (remember normal forms, separating different entities into different tables). I didn’t know about JOINs. I didn’t know one-to-one, one-to-many, many-to-one, many-to-many cardinality relationships.

I learned all those stuff when I was 19 and it was the time that I concluded all databases I have designed for 4 years were bullshit. Developers love writing SQL. But some don’t. Because maintaining physical schema sometimes can be frustrating and erroneous as in my story.

Imagine all you have is bunch of Java classes representing entities. Done. ORMAN handles database normalization, JOINs, foreign keys, indices for you.

Assume you have a small Android (Java) app or game, and you want to use a local database. Your program is 350 kb. If you add Hibernate, It is now 4 MB and it will be fast as much as your grandpa! On the other hand, ORMAN is around 150 KB and operates on your database very efficiently.

To be honest, I write this framework for Android. However it runs on desktop Java SE programs as well.

If you plan to use ORMAN on backend of your service or a mission-critial program, then  you’re doing it wrong. It is simply not designed for that.

Current status

ORMAN is licensed under Apache 2 open source License. The source code and latest build are available on GitHub. There is also a Wiki that I’m trying to document all the details of usage. ORMAN works with SQLite, SQLite on Android and MySQL. As I said before, it is not an enterprise solution and only designed for small usages.

Currently, my two friends contribute helping development of the framework: @0ffffffffh and @berkerpeksag. However, we need contributors to the framework that can write tests (we don’t have LOL), resolve issues and write useful features. We also need users for the framework, especially Android app developers.  It is not difficult to contribute ORMAN source code, it is pretty well documented and easy to understand.

We are not pro coders and this project is really an infant right now even it has over 10,000 lines of code.

Code examples

I won’t give code snippets here. If you spend just a few minutes on Wiki, I’m pretty sure that you’ll get the concept.

Lessons learned

In fact, we haven’t even released a stable version yet. However there are a few things I learned from this project. :)

  • SQL** standards** are useless: I designed SQL Query Builder part of framework to handle the ISO:SQL-1999 standards, and guess what, many DBMSes do not even obey SQL standards. It was difficult to write a query generator that can work on both SQLite and MySQL.

  • Do versioning: When you have something up and running, start versioning. We didn’t and yet we still don’t have version numbers. FFFFUUUUUU.

  • Design patterns: This project helped me exercise many design patterns in one project.

  • **Marketing: **It’s been 5 months and this is first blog post about it. How come it can have many users and we can collect feedback? We missed that part, indeed. But there’s still a chance out there and I’ll be writing on ORMAN on this blog.

  • **Demo or Die: **It is like PICS OR IT DIDNT HAPPEN. We have a few demos but they are for just us to manually test the features while implementing them. I’m really planning to write an Android app after my internship is over.

  • **Design first: **I don’t like first building stuff and then changing architecture on future iterations afterwards. I’m kinda opposed to Agile (because I have no work experience yet). In this project, designing the whole architecture first helped me solving many FFFFUUUU-class problems in a few lines of code on later stages.

  • Tests: To be honest, I’m not a test guy. All I know is we should have bunch of tests in this project, indeed. We don’t have them yet, but we’re looking for a brave coder to write tests for us. That’s the only way to make sure that we are close to be bug-free. We currently have 0% code coverage theoretically.

  • Read code and docs: I love writing documentation and I read docsa lot. That’s a good practice to write useful docs and references. At some points, I stuck on design considerations and cheated from other ORM frameworks. But the final decision was always the philosophy and aims behind ORMAN.

  • **Isolation and low coupling: **A very useful software development principle indeed. If you apply design patterns appropriately, you will not have ripple effect between different parts of the project and it will be much easier to integrate new stuff.

Now that’s the end of the story for now. You can read more about ORMAN and let us know if you are planning to develop something with it. We’d love to hear from you.

P.S. The word “orman” stands for _“forest” _in Turkish.