Deferred Lobs feature suggestion

[aehimself]

Offtopic - why are we that much attached to properties stored as strings...? Why not to introduce a new "settings" class like "Zeos" and put our settings there as enums, integers, etc? So instead of ZDataSet.Properties.Values['whatever'] = 'True' you could simply say ZDataset.Zeos.Whatever := True.

If it was like this from the beginning and it's now considered legacy how long do we plan to carry this on?

Is there any advantage of this which I can not see yet?

[marsupilami]

Offtopic - why are we that much attached to properties stored as strings...? Why not to introduce a new "settings" class like "Zeos" and put our settings there as enums, integers, etc? So instead of ZDataSet.Properties.Values['whatever'] = 'True' you could simply say ZDataset.Zeos.Whatever := True.

If it was like this from the beginning and it's now considered legacy how long do we plan to carry this on?

Is there any advantage of this which I can not see yet?

I think that having the strings is much mor flexible for several reasons:

• It is is much more simple to load Strings and lists of Strings from ini files. Having a new class with members etc would comlicate things in most use cases that use this, I think.
• Saving and loading human readable values for enums has to be done with RTTI and is a nightmare. I did that for the web service driver and don't want users to need to learn how to do that.
• Currently it is perfectly possible to write a driver that is not integrated into Zeos. This driver can have its own options, that the main Zeos doesn't need to know about. I think a new class would complicate things in this kind of use case.
• PostgreSQL uses a kind of connection string where one set options to use for the server. I have been thinking about implementing something where every entry in properties that starts with pg_ becomes an option in this connection string. This would allow setting any PostgreSQL option - not only the ones that Zeos is prepared to set. But could get impossible or clumsy to do when we use a settings class.

Best regards,

Jan

[aehimself]

Makes sense, but I disagree with the serialization part. I usually have a settings window in my application (or a settings application in headless programs), the user doesn't have to touch the settings file. It's possible but they must know what they are doing, end of story :)

Serializing enums only requires a bit of code:

Code: Select all

Const
 FONTSTYLE_BOLD = ' bold';
 FONTSTYLE_ITALIC = ' italic';
 FONTSTYLE_UNDERLINE = ' underline';
 FONTSTYLE_STRIKEOUT = ' strikeout';

Class Function TMyFont.StringToStyle(Const inStyleString: String): TFontStyles;
Var
 s: String;
Begin
 s := ' ' + inStyleString.Trim.ToLower;
 Result := [];
 If s.Contains(FONTSTYLE_BOLD) Then Result := Result + [fsBold];
 If s.Contains(FONTSTYLE_ITALIC) Then Result := Result + [fsItalic];
 If s.Contains(FONTSTYLE_UNDERLINE) Then Result := Result + [fsUnderline];
 If s.Contains(FONTSTYLE_STRIKEOUT) Then Result := Result + [fsStrikeOut];
End;

Class Function TMyFont.StyleToString(Const inStyle: TFontStyles): String;
Begin
 Result := '';
 If fsBold In inStyle Then Result := Result + FONTSTYLE_BOLD;
 If fsItalic In inStyle Then Result := Result + FONTSTYLE_ITALIC;
 If fsUnderline In inStyle Then Result := Result + FONTSTYLE_UNDERLINE;
 If fsStrikeout In inStyle Then Result := Result + FONTSTYLE_STRIKEOUT;
 Result := Result.TrimLeft;
End;

It all comes down to preferences I suppose. I also don't want to hijack the topic :)

[Fr0sT]

Serializing enums only requires a bit of code:

With "array[TFontStyle] of string " you can replace multiple if's by loop; next step would be GetEnumName/GetEnumValue

Regarding the options: yep they're quite cumbersome. But wide range of supported engines and options requires flexibility that only strings have. Nevertheless, some properties are already transparently mapped to TStrings - like connection properties. I guess it wouldn't be too hard to implement TZParams = class(TStrings) that would expose some generic properties.