mORMot Open Source

gururamnath

Member

Registered: 2011-11-28

Posts: 2

A simple ORM based on mORMot DB Libraries

Hi,
I'm in the process of creating a very simple ORM based on your DB library. It uses new RTTI and is similar to that of the .NET MicroORM - PetaPoco (http://www.toptensoftware.com/petapoco/ ). I'm wondering if you would like to have it added as part of mORMot framework itself ? Here are couple of things I have implemented and I think will be useful :

1) Uses regular Delphi TObject class as entity class
2) Uses RTTI and attributes for finding column information on the fly
3) Uses RTTI Cache to improve column information lookup
4) Ability to use SQL in the ORM
5) Uses .NET's T4 template to generate the Delphi classes for each Tables instead of hard coding each one them.

I just looked at the TMS Software announcement and it almost resembles that of the one I'm creating.

-regards,
Guru Kathiresan

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,589

Website

Re: A simple ORM based on mORMot DB Libraries

If I understand you well, the main differences will be:
- Using a regular TObject class as entity class;
- No Client-Server architecture - this is a regular ORM with persistence framework;
- Reverse engineering feature.

This is a good idea, but I think it may be separated to our little mORMot, which nature is to be a Client-Server RESTful ORM.
If you want, we can host it for free here - I can create a repository or a sub-folder for you.

The Reverse engineering feature is a tought one.
It is on my to-do list for mORMot.
As I wrote in this BLOG post, another "external" type is to be included - named TSQLRecordMappedAutoID and TSQLRecordMappedForcedID class:

For the ORM mapping of external tables, I'd like to implement at least two new TSQLRecordVirtual classes:
- A TSQLRecordExternal class, inheriting from TSQLRecordVirtualTableAutoID, which will handle a direct storage of TSQLRecord published field content with all our ORM high-level types (including dynamic arrays or such), just like the features provided with the SQLite3 engine; - this one is already implemented in rev. 1.15
- Two TSQLRecordMappedAutoID and TSQLRecordMappedForcedID class, inheriting from TSQLRecordVirtualTableAutoID or TSQLRecordVirtualTableForcedID classes, which will introduce a column mapping between the ORM content and the database content (see next paragraph). - this one is my to-do list
(...)
If you need to access a lot of existing data from a previous project, the new TSQLRecordMapped* classes will allow mapping of any existing table on any database: that is, you could define the table or columns names corresponding to the TSQLRecord published properties, mapping high-level Delphi types (like an enumeration, a set or even a dynamic array mapping a master/detail tables JOIN) from and into any values at the DB level - some reverse engineering guidance could be introduced at this level;
(...)

For your idea of data persistence, why not just make a fork of dorm using our light DB library?

Creating an ORM, even light, is always a lot of work.
It is always a good idea to look at what is existing.
You are on the good direction.