[Suggestion] group and declare as constants all supported values of Parameters

[Fr0sT]

Currently all names of Parameters of connections, datasets, transactions are used as literals. This not only is prone to mistakes but also significantly complexes the usage. One can use Zeos for years not knowing which parameters are available. My suggestion is to create separate unit where all the parameter names will be declared as named constants. Thus everyone could inspect the unit and learn the possibilities.
I'm ready to implement this task but I want to be sure it will be accepted.

[marsupilami]

Hello Fr0st,

I do like that Idea to a degree. But imho the even better way would be to document the available parameters in a kind of manual. I started a new approach to a manual. The current verion can be downloaded in the files section. Also I started documenting parameters in the Wiki. See https://sourceforge.net/p/zeoslib/wiki/ ... arameters/

What do you think?

If you still want to go the route with a separate unit then we surely can do that. In that case I would suggest one unit per driver. But we would have to see if there are parameters that affect the component layer and how we document them. I could use that as a start for the manual later on anyway.

With best regards,

Jan

[Fr0sT]

Hello Jan,
I'm glad you support my idea.
Concerning division of parameters by driver: there are plenty of parameters that are common to all drivers. So we'll need one unit for common constants anyway. Driver-specific parameters could be placed in ZPlain*Constants units. In any case parameters could be defined for connections, datasets and transactions - if that's what you meant by component layer?

[Fr0sT]

So what decision we'll make? I suggest this:
- One new unit ZCommonConstants for values that are used by all drivers (and maybe for some other things).
- Driver-specific values will be added to ZPlain*Constants units
- I suggest to call these constants ConnProps_*, TransProps_*, DSProps_*, f.i. ConnProps_CodePage, ConnProps_ControlsCP

[marsupilami]

Hello Fr0st,

you really seem to eat up my ressources with all your changes. I only have a maximum of one hour per day that I can spend on Zeos.

Getting back to this topic: Let me talk with the guy who kept Zeos alife for the past years. I value his opinion. I assume, I can call him today or tomorrow.

By the way: What do you think about becoming a Zeos developer and getting access access to the SVN? Do you use the Zeos test suite?

With best regards,

Jan

[Fr0sT]

Hello Jan,
I guess the suggestions/patches are better than just requests anyway

Yep, talk with the guy of course.

Well, your offer is very flattering for me! I have plenty of things I'd wish to improve in Zeos. But I still can't say I fully realized the structure so for somewhat valuable changes I'd need advice anyway. And I'm still not familiar with SVN, it just frightens me compared to Git . But I could start with simple commits to warm up.
I've tried to build and run test suite some time ago and it succeeded except some string conversion tests which I reported to tracker but I haven't examined it thoroughly.

[marsupilami]

Hello Jan,
I guess the suggestions/patches are better than just requests anyway

Yes - they are. I am happy about that situation. Applying patches instead of hunting down things myself is much better

Yep, talk with the guy of course.

Soo - I talked to him. In the end he suggests this: have one file for all parameters. Something like ZDbcDriverProperties.pas or something like that. As far as he remembers all parameters are on the DBC level. So the DBC subdirectory should be the best place. Some of the parameters work on the connection and some of them work on statement level. These constants should be surrounded by ifdefs in the new file to disable them if the corresponding driver is disabled. You can find the corresponding definitions in the Zeos.inc, like {.$DEFINE ZEOS_DISABLE_MYSQL}.
If you start this work, I have one more request: If you know what a parameter does, write a small comment in the new parameters file. That would help me a great deal later on when I will try to update the manual.

Well, your offer is very flattering for me! I have plenty of things I'd wish to improve in Zeos. But I still can't say I fully realized the structure so for somewhat valuable changes I'd need advice anyway. And I'm still not familiar with SVN, it just frightens me compared to Git . But I could start with simple commits to warm up.

Hmmm - I talked to Michael (EgonHugeist) and he agrees with me that the patches you supply are good. So why not? If you feel unsure about something we always can talk. Either here on the forums or via E-Mail or via Skype or by other means. I had some very long discussions with Michael about the internal API and about what can be expected from developers who use Zeos too. And honestly I also don't fully understand the structure of Zeos.
Regarding SVN: You might want to check out the SVN compatibility of Git. I do remember that Git can work a s a kind of SVN client too and that you can do some things using Git.

I've tried to build and run test suite some time ago and it succeeded except some string conversion tests which I reported to tracker but I haven't examined it thoroughly.

I remember those bug reports about string constant conversions. And I remember that I didn't see a good way to handle this. *sigh* But then - the test suite isn't perfect. What I would ask of you is to try to run the test suite when you changed code. Just to see that your new code doesn't cause any of the tests to fail that worked before. It would be even better if you could write up tests that test new functionality you implement. I still have some code here from another developer to integrate into the test suite to test the new PostgreSQL GUID field support.

[marsupilami]

Addendum: I put you into the developer group on Sourceforge. That should give you access to the SVN. You need to check out using https, otherwise you will not be allowed to chek in your changes using your sourceforge username and password. I also reconfigured the Wiki to allow everybody to modify and create pages. Until now this wasn't possible.

One more note: I want to try to make a release of Zeos 7.2 Since Zeos 7.2 is in RC state already we usually try to not add new features to that branch but only do bug fixes. So maybe you want to apply your changes regarding exceptions, using insert into returning and so on to Zeos 7.3. Zeos 7.3 is more or less Zeos 7.2 with two added drivers. According to Michael there are no other changes in 7.3 (yet). Michael usually copies the changes from Zeos 7.2 to Zeos 7.3 about once per week or every other week.

Sooo - my hour of Zeos is up for today Let me know what you think.

Best regards,

Jan

[Fr0sT]

Hello Jan,
I made the main part, it wasn't hard but only messy sometimes.
As some of the parameters are used in ZUrl and ZCompatibility units, I had to place the unit inside core\ folder to keep the hierarchy of uses. Let me know if dbс\ is preferred.
Currently there are 43 connection and dataset properties declared and about 50 left
I guess many users weren't suspecting about most of these options

For now, I have some questions:
1 - Is it acceptable to correct parameter names? There are typos in 'cashedblob' and 'timewiteformat' parameters. Unfortunately this could be a breaking change for user apps.
2 - Is it acceptable to change case of some parameter names to camel case? Just a cosmetic change, this won't make difference as stringlist searches for names without case-sensivity.
3 - Parameter 'AutoEncodeStrings' is only checked against 'ON' value while other parameters of "BOOL" type are checked against many values like YES/TRUE/ON/<>0 etc. I guess it's not a desired behavior and the parameter should be changed to accept all variety of values?

[marsupilami]

Hello Fr0st,

Hello Jan,
I made the main part, it wasn't hard but only messy sometimes.
As some of the parameters are used in ZUrl and ZCompatibility units, I had to place the unit inside core\ folder to keep the hierarchy of uses. Let me know if dbс\ is preferred.
Currently there are 43 connection and dataset properties declared and about 50 left
I guess many users weren't suspecting about most of these options

This is good news. Honestly I am surprised about having properties in ZCore. This is where things get messy. In my opinion it makes sense again to have them in separate units again. Something like a ZParams.pas in core and a ZDbcParams in the dbc subdirectory. If we want to keep to one single unit for all params - then yes - core is the right point for defining them.

For now, I have some questions:
1 - Is it acceptable to correct parameter names? There are typos in 'cashedblob' and 'timewiteformat' parameters. Unfortunately this could be a breaking change for user apps.

In my opinion we can't remove them from Zeos 7.2 because it already is in RC state officially. I suggest to keep them and introduce paramaters with the correct spelling. In 7.3 we could deprecate the old parameters and then we could remove them in a later version like 7.4.

2 - Is it acceptable to change case of some parameter names to camel case? Just a cosmetic change, this won't make difference as stringlist searches for names without case-sensivity.

In my opinion that is totally acceptable.

3 - Parameter 'AutoEncodeStrings' is only checked against 'ON' value while other parameters of "BOOL" type are checked against many values like YES/TRUE/ON/<>0 etc. I guess it's not a desired behavior and the parameter should be changed to accept all variety of values?

Yes - it should indeed be correted. Although I am sure that parameter will be obsolete at some future Zeos version.

With best regards,

Jan

[Fr0sT]

Hello Jan,

This is good news. Honestly I am surprised about having properties in ZCore. This is where things get messy. In my opinion it makes sense again to have them in separate units again. Something like a ZParams.pas in core and a ZDbcParams in the dbc subdirectory. If we want to keep to one single unit for all params - then yes - core is the right point for defining them.

TZCodePagedObject.SetConSettingsFromInfo only uses 'controls_cp' and 'AutoEncodeStrings', these values could even be passed as parameters instead of whole TStringList but TZUrl uses too much connection properties. So it seems that splitting the unit is the best idea as long as we try to keep units isolated.

In my opinion we can't remove them from Zeos 7.2 because it already is in RC state officially. I suggest to keep them and introduce paramaters with the correct spelling. In 7.3 we could deprecate the old parameters and then we could remove them in a later version like 7.4.

I didn't even intended to merge this change into 7.2 as there are too much changes. But what do you mean by 'deprecate'? Something like

Code: Select all

S := Values['NewCorrectName'];
if S = '' then
  S := Values['OldIncorrectName'];

?

In my opinion that is totally acceptable.

Yes - it should indeed be correted. Although I am sure that parameter will be obsolete at some future Zeos version.

OK!

[marsupilami]

Hello Jan,

This is good news. Honestly I am surprised about having properties in ZCore. This is where things get messy. In my opinion it makes sense again to have them in separate units again. Something like a ZParams.pas in core and a ZDbcParams in the dbc subdirectory. If we want to keep to one single unit for all params - then yes - core is the right point for defining them.

TZCodePagedObject.SetConSettingsFromInfo only uses 'controls_cp' and 'AutoEncodeStrings', these values could even be passed as parameters instead of whole TStringList but TZUrl uses too much connection properties. So it seems that splitting the unit is the best idea as long as we try to keep units isolated.

Ok. Let's do it like that.

In my opinion we can't remove them from Zeos 7.2 because it already is in RC state officially. I suggest to keep them and introduce paramaters with the correct spelling. In 7.3 we could deprecate the old parameters and then we could remove them in a later version like 7.4.

I didn't even intended to merge this change into 7.2 as there are too much changes. But what do you mean by 'deprecate'? Something like

Code: Select all

S := Values['NewCorrectName'];
if S = '' then
  S := Values['OldIncorrectName'];

?

With deprecating them I mean we announce in the release notes that these parameters will be removed in the future. Regarding who overwrites whom: Honestly I would prefer a way where the last parameter in a list is thge one that gets used. But since our drivers don't work like that, the NewCorrectName should always overwrite the OldIncorrectName paramater.

With best regards,

Jan

[Fr0sT]

Finally I did it in r4044!
All available properties, with descriptions, are listed - very good reference, I say