Attributes vs D7 tricks

h.hasenack · 2012-09-14 12:59:32

Hi ab

COnsidering the following class definition

  TSQLWorkbaseObject = class(TSQLRecord)
  private
    FName: UTF8String;
    FUserID: UTF8String;
  published
    property Name: UTF8String index 50 read FName write FName;
    property UserID: UTF8String index 20 read FUserID write FUserID;
  end;

I really dislike the "index 50" in order to define the string length. Could you implement (well, at least for post XE releases) that it first looks at class and property attributes before taking a look at this kind of data definition using the "index" keyword?
This would seriously clean up our code from strange statements while still allowing compatability with earlier versions of Delphi.

Regards - Hans

mpv · 2012-09-14 13:13:21

I try to work with class and property attributes in XE via new RTTI (TRttiContext e.t.c.) classes and got some problems:
1) An error EInsufficientRtti occurs - not for all cases new RTTI is present
2) VERY slow performance of new RTTI. Very slow.
3) It not work in FPC

So in my opinion using new RTTI is early now.

h.hasenack · 2012-09-14 15:05:57

Dou you have a profiler (like AQTime) to find out where it's slow? I may be of help there as I am quite experienced in optimizing code.

Hans

h.hasenack · 2012-09-17 06:50:25

mpv wrote:

I try to work with class and property attributes in XE via new RTTI (TRttiContext e.t.c.) classes and got some problems:
1) An error EInsufficientRtti occurs - not for all cases new RTTI is present
2) VERY slow performance of new RTTI. Very slow.
3) It not work in FPC
So in my opinion using new RTTI is early now.

1) This one is new to me Why/Where does it happen?
2) This should be fixable by some serious profiling and optimization sessions. If it's slow at generating/verifiying the DB metadata: that's not such a big deal. If it's slow at fetching/retrieving normal data then it definitely IS a big deal.
3) I assume using compiler directives could fix this. As stated before: I would prefer using the new RTTI, but defenitely NOT leave out the "old way index 50", not even in the same delphi version. If an app uses the new rtti to define attributes, however, this should precede the "index 50" definition. If it does NOT use attributes, it should simply use the old "index 50" definition.

Yes it would introduce some extra complexity in your source code. On the other hand, I think the future will drive us more into the class attributes direction. It's a cleaner way of implementing this. I am quite sure that in time it will be taken up by the (brilliant) guys that wrote the FPC. But it wont be ready not tomorrow.

Hans

mpv · 2012-09-17 09:12:55

1) EInsufficientRtti occurs for example for some method signatures if you try to call TRttiMethod.MethodKind, for example for such: myMethod(const Args: array of const): boolean;
2) When I say about slow performance of new RTTI I mean calls to TRttiType.GetFields, GetProperties, GetIndexedProperties, GetMethods, TRTTIMethod.GetAttributes and so on. For now I cache result of this calls to my own structures for quick access in future.
In general I agree with you - using new RTTI is comfortable. Actually I use it.. But as far as I know AB use Delphi7 and in mOTMot road map is migrating to FPC, so.....

ab · 2012-09-18 05:39:32

@h.hasenack
Using attributes does make sense with newer versions of Delphi.
It could be more readable, you are right.

As mpv mentioned, I mostly use Delphi 7 and in the mORMot roadmap, we are migrating to FPC, in which attributes have a diverse syntax.

@mpv
In mORMot, RTTI is already cached in TSQLRecordProperties per-class instance.
We may easily use the new RTTI, without no performance penalty.

Our purpose was to let the class definition be as "generic" as possible: since it is to be used on both client and server side, we did not want to add unneeded attributes on it.
Filters/Validation features included is much more powerful than this attribute syntax.
Even "index ...." should be specified with a fluent interface.
In all cases, the external DB mapping will be specified not by attributes, but by a fluent interface in code, only on the server side.

Thanks for the feedback.
If you have some code to propose, I'd merge it with pleasure to the framework trunk.

h.hasenack · 2012-09-18 06:54:57

>>If you have some code to propose, I'd merge it with pleasure to the framework trunk.

Will do, once I really get the hang of it.

Regards

ab · 2012-09-18 07:18:19

Thanks a lot for your ideas and proposals!

mORMot Open Source

#1 2012-09-14 12:59:32

Attributes vs D7 tricks

#2 2012-09-14 13:13:21

Re: Attributes vs D7 tricks

#3 2012-09-14 15:05:57

Re: Attributes vs D7 tricks

#4 2012-09-17 06:50:25

Re: Attributes vs D7 tricks

#5 2012-09-17 09:12:55

Re: Attributes vs D7 tricks

#6 2012-09-18 05:39:32

Re: Attributes vs D7 tricks

#7 2012-09-18 06:54:57

Re: Attributes vs D7 tricks

#8 2012-09-18 07:18:19

Re: Attributes vs D7 tricks

Board footer