Adding some generic-based methods to mORMot

ab · 2013-03-28 15:27:26

We have just added a TSQLTable.ToObjectList<T: class>() method.
See http://synopse.info/fossil/info/0549ba7168

I want to add some generics-based methods to mORMot, for newer versions of Delphi.

My first concern is that FreePascal does not offer the same syntax.
http://wiki.freepascal.org/Generics
I suppose some $ifdef... will be necessary here..

What do you think of it?
Have you some method prototypes to propose?

esmondb · 2013-04-02 10:53:22

It looks like the latest freepascal offer the Delphi syntax as an alternative:

http://wiki.lazarus.freepascal.org/User … elphi_mode

ab · 2013-04-02 11:14:44

esmondb wrote:

It looks like the latest freepascal offer the Delphi syntax as an alternative:
http://wiki.lazarus.freepascal.org/User … elphi_mode

I was not aware of that.
Sounds pretty enough for our purpose.

Since we are currently working with the FPC 2.7.1 branch, it is very good news!

Very nice!

We are preparing the implementation of "Unit Of Work" concept (from DDD) into mORMot.
I suppose it will rely on generics, since it is mostly about working with classes.
Then this "Unit Of Works" set of classes will use the ORM layer of mORMot to ask for the data.
So it will be designed to work on both Client and Server side, even if a pure DDD model would expect it to be implemented on the Server side only.

h.hasenack · 2013-04-02 12:03:28

Yes, generics will make us (me) very happy. What would be great too is to have (limited) TValue support foor communication between server and client, and maybe even in TSQLRecord as supported property type.

ab · 2013-04-02 12:10:54

What would be the benefit of using TValue in addition to the variant type, which is already available?

Do you have some ideas about the the methods which may benefit of having a new generic signature?
Most of the time, using a TSQLRecordClass sounds preferred to me, since it is faster and cross-version safe, but when you want to retrieve direct-to-work TSQLRecord sub-classes instances, generics could make sense (like with the new ToTObjectList<T> method).

h.hasenack · 2013-04-25 13:13:40

a bit late, but coming back to TValue..
Better than variants because:
1) It's way faster
2) contains natively rtti info about the data coming with the TValue
3) Very easy to extend and re-use in many classes (like the generic collections)
4) It is user intensively in the firemonkey framewwork to transport data between controls and the rest of the applications
5) It's an important part of the livebinding model. And the more I use it, the more I like it I must say.

I have just created helper classes for reading and writing arbitrary TValues, and it supports about all except pointers , procedures, interfaces methods and unknown.
Adding support for interfaces can be done, but was no issue to me.

I can send you the sources if you want to base your json serialaizer on my "dfm" serializer. I'll be out of office next week though.

Regards - Hans

Last edited by h.hasenack (2013-04-25 13:16:34)

ab · 2013-04-25 13:44:19

Could you please add a Feature Request ticket for TValue support in ORM and JSON marshaling?

h.hasenack · 2013-04-25 14:22:54

Done: http://synopse.info/fossil/tktview/5084 … 46f9757fe6

ab · 2013-04-25 18:33:45

Why use a blob and not a json encoding as with variants?

h.hasenack · 2013-04-26 06:38:14

Blob: for load/save speed and compactness. I use a blob to store my DFM compoatible encoded TValue's. Decoding and recording the DFM stream with ObjBinToText and ObjTextToBin allows easy debugging and checking of the stored values.

Off course, when using JSON encoding one could just as well use a Text memo field. Primarily, I use BLOB because of it's "unlimited" field size, not because it is binary. The binary choice is because I use my DFM encoded files in binary format.

ab · 2014-12-29 16:46:12

Not a high priority feature request IMHO, since it sounds to be needed only with some existing code. And it would break compatibility with older versions of Delphi, and FreePascal (i.e. our Linux support).

External input (via a github fork maybe) may be the preferred way.
If anyone is willing to implement it, we would be very pleased to validate its code patch proposal.

mORMot Open Source

#1 2013-03-28 15:27:26

Adding some generic-based methods to mORMot

#2 2013-04-02 10:53:22

Re: Adding some generic-based methods to mORMot

#3 2013-04-02 11:14:44

Re: Adding some generic-based methods to mORMot

#4 2013-04-02 12:03:28

Re: Adding some generic-based methods to mORMot

#5 2013-04-02 12:10:54

Re: Adding some generic-based methods to mORMot

#6 2013-04-25 13:13:40

Re: Adding some generic-based methods to mORMot

#7 2013-04-25 13:44:19

Re: Adding some generic-based methods to mORMot

#8 2013-04-25 14:22:54

Re: Adding some generic-based methods to mORMot

#9 2013-04-25 18:33:45

Re: Adding some generic-based methods to mORMot

#10 2013-04-26 06:38:14

Re: Adding some generic-based methods to mORMot

#11 2014-12-29 16:46:12

Re: Adding some generic-based methods to mORMot

Board footer