Skip to content

Commit 49c9131

Browse files
committed
removed comment about default session behavior
1 parent f9a7433 commit 49c9131

File tree

1 file changed

+0
-7
lines changed

1 file changed

+0
-7
lines changed

README.md

-7
Original file line numberDiff line numberDiff line change
@@ -50,13 +50,6 @@ In version 1.0, empty fields in FileMaker were returned as an empty string. In v
5050

5151
If you'd like to continue with the old behavior your can change the `empty_strings_to_null` config value to false to keep with the empty strings. Otherwise, if you have any code which relies on empty fields being returned as an empty string, you may need to refactor your code to work with the new behavior.
5252

53-
##### Minor - Changes to session management - Minor Change
54-
In version 1.0 the same FileMaker Data API session was used for all requests for about 15 minutes at a time, until the token expired. This token was stored in the Laravel Cache between requests. This behavior has been changed in version 2.0 to work when cache is not configured.
55-
56-
By default, in version 2.0 a Data API session lasts for only the duration of one request to your Laravel app. Login is performed the first time you use request data from the Data API. The session is ended and a logout is performed after the response has been sent to the browser through the use of [terminable middleware](https://laravel.com/docs/11.x/middleware#terminable-middleware).
57-
58-
If you have any code which relies on the Data API session being reused between requests to your Laravel app, such as setting a global field once and then reading it across multiple page loads of your Laravel app, you will need to either change this behavior by setting ` 'cache_session_token' => true` in your FileMaker connection config or refactor your code to work with the new behavior.
59-
6053
##### Minor - Improvements to whereNot logic
6154
There were some cases where whereNot may return results that were probably not correct or expected. This has been fixed in version 2.0. If you have any code which relies on the old, incorrect behavior of whereNot, you may need to refactor your code to work with the new corrected behavior.
6255

0 commit comments

Comments
 (0)