Use stateless flag from toolkit.ini it is present to override value in $_options array. #39

Scott-Cam · 2015-02-16T00:27:04Z

The stateless flag from the toolkit.ini should be used if it is present in the config file. This value should override the stateless flag set in the $_options array.

alanseiden · 2015-02-17T01:57:53Z

Looks good. To clarify for others reading this, $_options is an array in ToolkitService.php that contains default values at first. By default, stateless is false. Scott is providing a way to change the default to true via toolkit.ini.

alanseiden · 2015-02-17T02:02:37Z

Scott, one problem, I think. This solution will change the default for everyone, won't it? Because stateless=true by default in toolkit.ini. All the innocent stateful users will suddenly get stateless behavior. Don't get me wrong, I think stateless should have been the default from the start, but now people's applications may start behaving differently. Am I correct about this?

Scott-Cam · 2015-02-22T23:40:14Z

Yes, I'll update the toolkit.ini to set it to false and put a note there that it should be updated unless statefull connections are required.

alanseiden · 2015-02-23T03:25:25Z

Agreed, but will a value of false affect CW users? Their default was always true (to be compatible with Easycom default behavior).

Scott-Cam · 2015-02-27T03:42:09Z

Yes, it will. So I guess it comes down to (in)convenience :) , what
benefits the majority of the users? Should the default be statefull or
stateless? Do you have a feeling (or hard numbers) on which is used more?
I think that since this is going in a new release it could be either, as
long as it is well documented, release notes, readme, in the ini file.
Then it is up to the user to decide which they prefer (or need) and
should be tested in a development environment prior to upgrading for
existing users, and new users would have to have a specific use case to
need the flag to be flipped (if the default is changed to stateless).

Let me know what you think and I can set it either way.

Scott

On 2/22/2015 8:25 PM, Alan Seiden wrote:

Agreed, but will a value of false affect CW users? Their default was
always true (to be compatible with Easycom default behavior).

—
Reply to this email directly or view it on GitHub
#39 (comment).

alanseiden · 2015-03-03T14:30:45Z

Scott,

If we were starting over, I'd default to stateless. 50% of people's problems stem from people following the samples and thus using stateful+disconnect, or omitting any mention of stateless, thus using stateful mode without knowing it (with the dreaded default internal key /tmp/Toolkit). Stateless mode simplifies life for most users.

If we were building toolkit 2.0, we could make major changes, impair backward compatibility, and break people's code if sufficiently documented. Because we're only working on 1.6.* or 1.7 at best, however, we must not break anyone's code. In the history of my toolkit involvement, I introduced only one bc break and it was because I corrected a bug, and even then, I included bug-compatible code that could be invoked via new .ini settings (the two "integrity" settings). This is IBM i, where users expect stability above all. This does make our job harder.

I think the only answer is to add a new setting that applies to the "new" toolkit, leaving the old CW setting as is. Then the old one could be set to true and the new one to false, along with a comment educating users that "true" is easier for most users.

alanseiden · 2015-03-06T21:34:36Z

We need a new, additional stateless setting that doesn't interfere with the old CW stateless setting. I don't see a way around that without breaking people's code.

Scott-Cam · 2015-03-06T23:13:48Z

Agreed. I'll take a look at adding it in.

Scott

On 3/6/2015 2:34 PM, Alan Seiden wrote:

We need a new, additional stateless setting that doesn't interfere
with the old CW stateless setting. I don't see a way around that
without breaking people's code.

—
Reply to this email directly or view it on GitHub
#39 (comment).

adamculp · 2015-07-23T20:21:33Z

Scott,

Did you get a chance to look at adding this in? I wanted to clean out this PR and at the moment it cannot be merged in.

Scott-Cam · 2015-08-08T03:46:54Z

Sorry was on vacation so took a while to get everything else done this week.

Added a new flag in the toolkit.ini and check if the call is being made from the compatibility wrapper or not to return the appropriate stateless flag. Did some testing (stepping through the code for various calls) to ensure the calls that were from the compatibility wrapper were using the stateless flag and those that were not were using the xmlstateless flag.

Take a look and let me know if you think that there are any further changes required.

alanseiden · 2015-08-11T14:56:37Z

Thanks, Scott. Will look!

chukShirley · 2016-10-25T16:23:07Z

@alanseiden Is this ready to merge?

alanseiden · 2016-10-25T16:29:58Z

@chukShirley The idea seems good, but what do you think of the flag's name? 'xmlstateless'. The flag's purpose is to change the default value of 'stateless' to true, for the regular toolkit (not CW). I think we should not use the word 'xml', because in the future, we may have json or other formats, and people shouldn't think this feature has anything to do with XML. How about calling it 'stateless_mode_default' or something like that? We could merge, if the name could be a bit better. Any ideas?

chukShirley · 2016-10-25T16:33:46Z

I like 'stateless_mode_default'. That seems more descriptive.

chukShirley · 2016-10-25T16:37:50Z

@Scott-Cam Can you rebase this branch and change the name of the flag?

adamculp · 2016-10-27T21:19:14Z

Will this break BC for those who may already be using the previous default?

clarkphp · 2016-10-27T21:39:05Z

@adamculp - This is a new flag which does not exist in the current Toolkit, although it does have a pre-existing, equivalent flag of a different name in the current toolkit. The two flags have the exact same purpose and functionality; one is set to a more proper default, while the other is left at the old, non-optimal-but-non-BC-breaking default.

The old one will read if using the CW, while the new one will be read if not using the CW. There should be no BC break because no one currently using the toolkit is using the new flag.

See lines 1753 through 1758 of ToolkitService.php in the pull request. (the name is changing to stateless_mode_default, though).

adamculp · 2016-10-27T22:02:17Z

Thanks Clark. I did not realize that since a previous comment said it was a toolkit.ini setting. Made me think it existed there previously.

…de value in $_options array. Add to constructor by adding to the array in getOptionalParams. Change default stateless flag to flase in the toolkit.ini to match existing functionality Add second stateless flag for XML toolkit. Check if call is being made from compatibility wrapper and use appropriate stateless flag.

Scott-Cam · 2016-11-06T16:36:20Z

Done, hopefully got it right (first rebase), the pull request is
updated. Let me know if there are any issues or additional changes
required.

Scott

On 10/25/2016 10:37 AM, Chuk Shirley wrote:

@Scott-Cam https://github.com/Scott-Cam Can you rebase this branch
and change the name of the flag?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#39 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJY6-nOAK-IxTSwcw69my7U_3Muj2S_gks5q3jBfgaJpZM4Dgwzn.

alanseiden · 2021-11-05T18:50:28Z

ToolkitApi/Toolkit.php

@@ -144,7 +145,7 @@ public function __construct($databaseNameOrResource, $userOrI5NamingFlag = '0',
        }

        // Optional params. Don't specify if not given in INI.
-        $this->getOptionalParams('system', array('v5r4', 'ccsidBefore', 'ccsidAfter', 'useHex', 'paseCcsid', 'trace', 'dataStructureIntegrity',  'arrayIntegrity'));
+        $this->getOptionalParams('system', array('stateless_mode_default','stateless','v5r4', 'ccsidBefore', 'ccsidAfter', 'useHex', 'paseCcsid', 'trace', 'dataStructureIntegrity',  'arrayIntegrity'));


@alanseiden Don't include 'stateless' here. That's only for the CW.

@alanseiden Around line 157, try something like:

if ($this->getConfigValue('system', 'stateless_mode_default')) { $this->serviceParams['stateless'] = $this->getConfigValue('system', 'stateless_mode_default'); }

alanseiden · 2021-11-05T18:51:30Z

ToolkitApi/Toolkit.php

@@ -1734,7 +1735,12 @@ public function getInternalKey()
     */
    public function isStateless()
    {
-        return $this->getOption('stateless');
+        if ($this->getIsCw()){


@alanseiden This isn't the place to make this change. 'stateless' from getOptions() is still the value to check.

Alan, see above comment about line 157.

alanseiden · 2021-11-12T19:57:47Z

ToolkitApi/toolkit.ini

+; Non-CW Stateless flag - default to true
+; This should be overridden if you require stateful connections
+; Set the default value of 'stateless' to true, for the regular toolkit (not CW).
+stateless_mode_default = true


@alanseiden Should default to false to retain traditional behavior (don't break applications by mistake).

alanseiden · 2021-11-12T19:59:13Z

ToolkitApi/toolkit.ini

-stateless = true
+; CW stateless flag
+; stateless mode is default for i5_connect (though automatically overridden if private conns are used)
+stateless = false


@alanseiden stateless flag for CW should be true by default as it currently is.

alanseiden · 2021-11-12T20:02:54Z

ToolkitApi/toolkit.ini

+; stateless mode is default for i5_connect (though automatically overridden if private conns are used)
+stateless = false
+; Non-CW Stateless flag - default to true
+; This should be overridden if you require stateful connections


@alanseiden Suggested comments instead:

; Non-CW (regular toolkit) Stateless default flag ; Set the default value of 'stateless' option, for the regular toolkit (not CW).

chukShirley assigned Scott-Cam Oct 28, 2016

Scott-Cam force-pushed the master branch from 8cec8ce to bcacdc6 Compare November 6, 2016 16:25

Rebasing and re-applying changes

11c949c

alanseiden reviewed Nov 5, 2021

View reviewed changes

alanseiden reviewed Nov 12, 2021

View reviewed changes

NattyNarwhal mentioned this pull request Nov 12, 2021

Rename stateless to i.e. cw_stateless #172

Open

alanseiden reviewed Nov 12, 2021

View reviewed changes

NattyNarwhal mentioned this pull request Nov 12, 2021

Updated #39: Use stateless flag from toolkit.ini it is present to override value in $_options array #173

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use stateless flag from toolkit.ini it is present to override value in $_options array. #39

Use stateless flag from toolkit.ini it is present to override value in $_options array. #39

Scott-Cam commented Feb 16, 2015

alanseiden commented Feb 17, 2015

alanseiden commented Feb 17, 2015

Scott-Cam commented Feb 22, 2015

alanseiden commented Feb 23, 2015

Scott-Cam commented Feb 27, 2015

alanseiden commented Mar 3, 2015

alanseiden commented Mar 6, 2015

Scott-Cam commented Mar 6, 2015

adamculp commented Jul 23, 2015

Scott-Cam commented Aug 8, 2015

alanseiden commented Aug 11, 2015

chukShirley commented Oct 25, 2016

alanseiden commented Oct 25, 2016

chukShirley commented Oct 25, 2016

chukShirley commented Oct 25, 2016

adamculp commented Oct 27, 2016

clarkphp commented Oct 27, 2016 •

edited

Loading

adamculp commented Oct 27, 2016

Scott-Cam commented Nov 6, 2016

alanseiden Nov 5, 2021

alanseiden Nov 5, 2021

alanseiden Nov 5, 2021

alanseiden Nov 5, 2021

alanseiden Nov 12, 2021

alanseiden Nov 12, 2021

alanseiden Nov 12, 2021

Use stateless flag from toolkit.ini it is present to override value in $_options array. #39

Are you sure you want to change the base?

Use stateless flag from toolkit.ini it is present to override value in $_options array. #39

Conversation

Scott-Cam commented Feb 16, 2015

alanseiden commented Feb 17, 2015

alanseiden commented Feb 17, 2015

Scott-Cam commented Feb 22, 2015

alanseiden commented Feb 23, 2015

Scott-Cam commented Feb 27, 2015

alanseiden commented Mar 3, 2015

alanseiden commented Mar 6, 2015

Scott-Cam commented Mar 6, 2015

adamculp commented Jul 23, 2015

Scott-Cam commented Aug 8, 2015

alanseiden commented Aug 11, 2015

chukShirley commented Oct 25, 2016

alanseiden commented Oct 25, 2016

chukShirley commented Oct 25, 2016

chukShirley commented Oct 25, 2016

adamculp commented Oct 27, 2016

clarkphp commented Oct 27, 2016 • edited Loading

adamculp commented Oct 27, 2016

Scott-Cam commented Nov 6, 2016

alanseiden Nov 5, 2021

Choose a reason for hiding this comment

alanseiden Nov 5, 2021

Choose a reason for hiding this comment

alanseiden Nov 5, 2021

Choose a reason for hiding this comment

alanseiden Nov 5, 2021

Choose a reason for hiding this comment

alanseiden Nov 12, 2021

Choose a reason for hiding this comment

alanseiden Nov 12, 2021

Choose a reason for hiding this comment

alanseiden Nov 12, 2021

Choose a reason for hiding this comment

clarkphp commented Oct 27, 2016 •

edited

Loading