Use expireAt as index #11

pepoviola · 2020-10-11T23:41:03Z

Hi @No9 / @yoshuawuyts, I was looking the pr #9 and looks really nice!! and triggered me the idea to check if we can skip the config step and keep the expiry feature.

I checked how this is handler in node.js and the connect-mongodb-session create an index with {expireAfterSeconds:0} and let the session to manage the expire as an absolute value.
https://github.com/mongodb-js/connect-mongodb-session/blob/master/index.js#L88-L94

I make some changes to mimic this behavior, but I don't know if creating the index in the connect function is the best way or we can add something like fn initialize to be called one time to create this index.
Also, mongodb runs the background process to delete expired items every 60 seconds, so any value of expire lower than that will not be respected.

I could be wrong on this idea and any feedback is welcome 😄

Thanks!

No9 · 2020-10-12T09:38:06Z

Hey @pepoviola
Thanks for getting involved - I like the shape of this PR as it has the foundation of catering for both the created and expire approaches.
89981b2#diff-b4aea3e418ccdb71239b96952d9cddb6R96

I think we should keep both options as the created approach allows for global control of the cache time and out of band management where as the expire approach in this PR is more aligned to prior art and allows for explicit management of the session length from code. I think both are valid use cases.

I'll put the rest of the comments inline.

No9 · 2020-10-12T09:39:20Z

README.md

-db.coll_session.createIndex( { created": 1 } , { expireAfterSeconds: 300 } ) 
-```
+To enable this [expiry feature](https://docs.mongodb.com/manual/tutorial/expire-data/#expire-documents-at-a-specific-clock-time) at `index` for `expireAt` is created when the client `connet`. Allowing then to use this property from the session to set the expiration of the document.



I think we should keep both approaches in the README as well as state when you would use one over the other.

No9 · 2020-10-12T09:41:36Z

src/lib.rs

    /// ```
    pub async fn connect(uri: &str, db: &str, coll_name: &str) -> mongodb::error::Result<Self> {
        let client = Client::with_uri_str(uri).await?;
+        let create_index = doc! {


This should probably be an external initialize as suggested in the PR commit message. It would fit with the builder approach in the tide example https://github.com/jbr/tide-example/blob/main/src/main.rs#L24 and allow us to support both global and local options

src/lib.rs

No9 · 2020-10-12T09:47:35Z

tests/test.rs

+    }
+
+    #[test]
+    fn test_check_expired() -> async_session::Result {


👍 Thanks for including the tests upfront :)

pepoviola · 2020-10-12T09:52:36Z

Hi @No9, thanks for the feedback!! 😄 . I will review the comments and make those changes.

I think we should keep both options as the created approach allows for global control of the cache time and out of band management where as the expire approach in this PR is more aligned to prior art and allows for explicit management of the session length from code. I think both are valid use cases.

Yes, having support of both approaches is really nice.

Thx!

pepoviola · 2020-10-12T12:15:16Z

Hi @No9, I just review the feedback and add this two ( more like initializers ) fn create_created_index_for_global_expiry / create_expire_at_index to create the indexes from the code. I also include the instructions for creating those through the mongodb client.

Thx!

No9 · 2020-10-12T13:01:30Z

Hey @pepoviola - Cool - This is great progress.

I think it's going to need something less wordy than create_created_index_for_global_expiry.
It's logically correct but the repetition of create_created doesn't flow.
Maybe use index as a verb and go for index_on_expiry_at and index_on_created but this might be too subtle for none native speakers? What are your thoughts?

I see you removed the reference to 12 Factor apps. I understand that it may not be directly relevant to the configuration section but we should have some overview of when you would use one option over another that captures the conclusions from this branch and the #8 issue.
Probably an Overview heading before the installation of configuration topics?
I am happy to add that on top of this PR if you would prefer.

I'll have a deeper look at the code later today but would good to get @jbr 's thoughts on this as well.

pepoviola · 2020-10-12T13:34:47Z

Hi @No9, thanks for the feedback 😄 . I just made those changes and add the overview section.
Thanks!

No9 · 2020-10-12T19:43:16Z

README.md

-This library utilises the document [expiry feature](https://docs.mongodb.com/manual/tutorial/expire-data/#expire-documents-after-a-specified-number-of-seconds) in mongodb to expire the session.
+## Overview
+This library allow you to utilises the document expiration feature based on a [specified number of seconds](https://docs.mongodb.com/manual/tutorial/expire-data/#expire-documents-after-a-specified-number-of-seconds) or in a [specific clock time](https://docs.mongodb.com/manual/tutorial/expire-data/#expire-documents-at-a-specific-clock-time) supported by mongodb to expire the session.



I was thinking something along the lines of
"The specified number of seconds approach is designed to enable the session time out to be managed at the mongodb layer. This approach provides a globally consistent session timeout across multiple processes but has the downside that all services using the same session collection must use the same timeout value.

The specific clock time clock time approach is where you require more flexibility on your session timeouts such as a different session timeout per running service or you would prefer to manage the session time out at the process level. This is more flexible but might lead to some perceived inconsistency in session timeout depending on your upgrade/rollout strategy."

Hi @No9, Neat!! If you want I can add those lines. 👍

@pepoviola If you're OK with it then lets add it inbetween the content that already there

Hi @No9, added 👍 . Thanks for the help!

jbr · 2020-10-14T19:22:18Z

README.md

+## Overview
+This library allow you to utilises the document expiration feature based on a [specified number of seconds](https://docs.mongodb.com/manual/tutorial/expire-data/#expire-documents-after-a-specified-number-of-seconds) or in a [specific clock time](https://docs.mongodb.com/manual/tutorial/expire-data/#expire-documents-at-a-specific-clock-time) supported by mongodb to expire the session.


Suggested change

## Overview

This library allow you to utilises the document expiration feature based on a [specified number of seconds](https://docs.mongodb.com/manual/tutorial/expire-data/#expire-documents-after-a-specified-number-of-seconds) or in a [specific clock time](https://docs.mongodb.com/manual/tutorial/expire-data/#expire-documents-at-a-specific-clock-time) supported by mongodb to expire the session.

## Overview

This library uses the document expiration feature based on a [specified number of seconds](https://docs.mongodb.com/manual/tutorial/expire-data/#expire-documents-after-a-specified-number-of-seconds) or a [specific clock time](https://docs.mongodb.com/manual/tutorial/expire-data/#expire-documents-at-a-specific-clock-time) supported by mongodb to expire the session.

jbr · 2020-10-14T19:25:18Z

README.md

+The specified number of seconds approach is designed to enable the session time out to be managed at the mongodb layer. This approach provides a globally consistent session timeout across multiple processes but has the downside that all services using the same session collection must use the same timeout value.

-This library utilises the document [expiry feature](https://docs.mongodb.com/manual/tutorial/expire-data/#expire-documents-after-a-specified-number-of-seconds) in mongodb to expire the session.
+The specific clock time clock time approach is where you require more flexibility on your session timeouts such as a different session timeout per running service or you would prefer to manage the session time out at the process level. This is more flexible but might lead to some perceived inconsistency in session timeout depending on your upgrade/rollout strategy.


i'm curious about the word "perceived" — is it actually consistent?

jbr · 2020-10-14T19:26:30Z

README.md

+db.coll_session.createIndex( { "created": 1 } , { expireAfterSeconds: 300 } );
+```
+
+Other way to set create the index is using  `index_on_created` passing the amount of seconds to expiry after the session.


Suggested change

Other way to set create the index is using `index_on_created` passing the amount of seconds to expiry after the session.

Another way to set create the index is to use `index_on_created`, passing the amount of seconds to expiry after the session.

jbr · 2020-10-14T19:26:54Z

src/lib.rs

        }
    }
+
+    /// Create a new index for the `created` property and set the expiry ttl (in secods).


Suggested change

/// Create a new index for the `created` property and set the expiry ttl (in secods).

/// Create a new index for the `created` property and set the expiry ttl (in seconds).

jbr · 2020-10-14T19:27:43Z

src/lib.rs

+        Ok(())
+    }
+
+    /// Create a new index for the `expireAt` property, allowing to expire sessions at a specific clock time.


Suggested change

/// Create a new index for the `expireAt` property, allowing to expire sessions at a specific clock time.

/// Create a new index for the `expireAt` property, in order to expire sessions at a specific clock time.

jbr · 2020-10-14T19:30:05Z

README.md

+The specified number of seconds approach is designed to enable the session time out to be managed at the mongodb layer. This approach provides a globally consistent session timeout across multiple processes but has the downside that all services using the same session collection must use the same timeout value.

-This library utilises the document [expiry feature](https://docs.mongodb.com/manual/tutorial/expire-data/#expire-documents-after-a-specified-number-of-seconds) in mongodb to expire the session.
+The specific clock time clock time approach is where you require more flexibility on your session timeouts such as a different session timeout per running service or you would prefer to manage the session time out at the process level. This is more flexible but might lead to some perceived inconsistency in session timeout depending on your upgrade/rollout strategy.


Suggested change

The specific clock time clock time approach is where you require more flexibility on your session timeouts such as a different session timeout per running service or you would prefer to manage the session time out at the process level. This is more flexible but might lead to some perceived inconsistency in session timeout depending on your upgrade/rollout strategy.

The specific clock time approach is for use cases when you require more flexibility on your session timeouts such as a different session timeout per running service or you would prefer to manage the session time out at the process level. This is more flexible but might lead to some perceived inconsistency in session timeout depending on your upgrade/rollout strategy.

pepoviola · 2020-10-17T12:59:09Z

Hi @No9 / @jbr, Thanks for the feedback! I updated the code according to but I have some questions related

I check the integration with tide and the sessionMiddleware have a default session expiry of 1 day, so when this library is used with tide the session will always have some expiry. So, the default session expire mechanism of the library will be only use where the library is used as stand alone. Also, related to this topic I wonder if it's more ergonomic to call initialize from new by default.
I couldn't use the ? in the example integration with tide because the From trait isn't implemented. Is this something we want to add?

Thanks a lot for the help!

pepoviola · 2020-11-09T23:14:13Z

Hi @jbr, can you review when you have time. Thanks!

jbr · 2020-11-09T23:21:35Z

@pepoviola thanks for mentioning me here but I think this is ultimately a @yoshuawuyts / @io9 PR to review. I don't know anything about mongo, and my only feedback was "we should provide sensible defaults so it's easy to get started," which it sounds like we're doing

pepoviola · 2020-11-09T23:29:35Z

Hi @jbr, thanks! I will wait for @yoshuawuyts or @No9.

pepoviola added 5 commits October 11, 2020 15:14

wip: use expire from session with mongodb index

89981b2

add tests and modify readme

db6a76f

typo

374d776

fmt

9129246

fmt tests

a5b3fe2

No9 reviewed Oct 12, 2020

View reviewed changes

src/lib.rs Outdated Show resolved Hide resolved

No9 reviewed Oct 12, 2020

View reviewed changes

feedback changes

50d5d1c

pepoviola added 3 commits October 12, 2020 10:26

add overvew and 12factor to readme

a94f090

change naming from feedback

459341b

fmt

345f977

No9 reviewed Oct 12, 2020

View reviewed changes

add more context to readme

92ec601

jbr reviewed Oct 14, 2020

View reviewed changes

pepoviola added 4 commits October 15, 2020 23:24

wip - move to initialize version

0735bda

fmt

281f623

clean up readme and add examples

a5bad73

changes to use initialize and the default expireAt mechanism

b49ea3d

pepoviola requested a review from No9 October 27, 2020 11:19

pepoviola added 5 commits December 20, 2020 14:19

change example to work with

6dbf35b

update deps

56a644a

improve ergonomics

bb65d43

fmt

af0f846

fmt

636f3a7

No9 merged commit 48bc322 into http-rs:session-as-object Dec 21, 2020

No9 mentioned this pull request Dec 21, 2020

Store as document fix and documentation on how to configure session expiry. #9

Merged

		## Overview
		This library allow you to utilises the document expiration feature based on a [specified number of seconds](https://docs.mongodb.com/manual/tutorial/expire-data/#expire-documents-after-a-specified-number-of-seconds) or in a [specific clock time](https://docs.mongodb.com/manual/tutorial/expire-data/#expire-documents-at-a-specific-clock-time) supported by mongodb to expire the session.

	Other way to set create the index is using `index_on_created` passing the amount of seconds to expiry after the session.
	Another way to set create the index is to use `index_on_created`, passing the amount of seconds to expiry after the session.

	/// Create a new index for the `created` property and set the expiry ttl (in secods).
	/// Create a new index for the `created` property and set the expiry ttl (in seconds).

	/// Create a new index for the `expireAt` property, allowing to expire sessions at a specific clock time.
	/// Create a new index for the `expireAt` property, in order to expire sessions at a specific clock time.

	The specific clock time clock time approach is where you require more flexibility on your session timeouts such as a different session timeout per running service or you would prefer to manage the session time out at the process level. This is more flexible but might lead to some perceived inconsistency in session timeout depending on your upgrade/rollout strategy.
	The specific clock time approach is for use cases when you require more flexibility on your session timeouts such as a different session timeout per running service or you would prefer to manage the session time out at the process level. This is more flexible but might lead to some perceived inconsistency in session timeout depending on your upgrade/rollout strategy.

Use expireAt as index #11

Use expireAt as index #11

Uh oh!

Conversation

pepoviola commented Oct 11, 2020

Uh oh!

No9 commented Oct 12, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pepoviola commented Oct 12, 2020

Uh oh!

pepoviola commented Oct 12, 2020

Uh oh!

No9 commented Oct 12, 2020

Uh oh!

pepoviola commented Oct 12, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

No9 Oct 12, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

No9 Oct 12, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jbr Oct 14, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pepoviola commented Oct 17, 2020

Uh oh!

pepoviola commented Nov 9, 2020

Uh oh!

jbr commented Nov 9, 2020

Uh oh!

pepoviola commented Nov 9, 2020

Uh oh!

Uh oh!

pepoviola commented Oct 12, 2020 •

edited

Loading

No9 Oct 12, 2020 •

edited

Loading

No9 Oct 12, 2020 •

edited

Loading

jbr Oct 14, 2020 •

edited

Loading