Get expiry date from session store

[Katze864]

Is there a way to load the expiry date from the database instead of resetting it every time the session is recreated?
This results in a long expiry time:

    let pool = SqlitePoolOptions::new()
        .connect("sqlite:database.db")
        .await
        .expect("Could not make pool.");

    let session_store = SqliteStore::new(pool.clone());
    let session = Session::new(None, session_store.clone().into(), Some(Expiry::OnInactivity(Duration::seconds(30))));

    session.save().await.unwrap();

    let new_session = Session::new(session.id(), session_store.into(), None);

    println!("Expiry date: {}", new_session.expiry_date());

[maxcountryman]

As it stands I think there's a conflict between configuring a default expiration (which is what the layer method does) and overloading that from the session API.

For example, the next time a session is initialized by the manager it will use the configured value (or default) and not whatever was set by Session::set_expiry since it has no knowledge of what's been persisted in the store and cannot load from the store directly at that point in its lifecycle.

It would be a breaking change to rely on the record because that's an async interface that must talk to the store to reconcile an expiration.

That said, that does appear to be what the Django implementation does: it loads the session cache and then reads and writes to it directly.

[longsleep]

@maxcountryman I guess this is where you wanted me to look - you linked issue 178 which made no sense to me - sorry.

Anyways in #207 is a change which solves this issue without breaking any of the existing tests nor changing any of the api. The only requirement is that one needs to load or get from the session before calling any of the expiry retrieval related functions to get the actual stored expiry - maybe that can be done as an intermediate solution before a breaking rework of the expiry api (e.g. async).

[maxcountryman]

#178 explains your issue perfectly: you are confused about Record and Expiry and the fact that it's not possible to derive Expiry from Record.

Please look at the type Record. It has no relation to Expiry. That is crucial.

Because of this fact, you cannot create an Expiry with it. The methods you mentioned on Session require Expiry. For example, the date-time is derived from Expiry.

It is not correct to guess which variant of Expiry was intended; this is simply wrong and does not solve the problem.

I mentioned previously that the solution here is to associate Expiry with the Record as e.g. a property of the Record type. But this is a significant breaking change and I'm not convinced it's worth the churn.

[longsleep]

Wha you explain is something entirely different from what is described in the title of this discussion and what is made possible with my PR.

You are interchanging "expiry date" with "Expiry type". Those are not the same.

I don't want to know how the expiry was come to be (which is what the Expiry type defines) - I need to know when the session actually expires (which can be represented with one of the Expiry type variants).

When one loads the expiry date into the corresponding Expiry type variant, this does exactly what it should do, not updating the expiry date of the session further unless explicity told to do so by other means.

A different approach to solve this, would be to add a new async function age to the session, which loads the record and returns it expiry date.

[maxcountryman]

I need to know when the session actually expires

The expiry methods already correctly do this. (Please stop arguing with me about this: they aren't written for your use case, they're written for a specific semantic.)

You don't seem to understand that the answer to that question is a derivative of Expiry and not what might or might not be in a session store.

The only part of this workflow that doesn't work as desired is setting an expiry via set_expiry. To be more clear, your misunderstanding is leading you to the incorrect conclusion that this isn't working as intended: it is working as intended.

I am not interested in changing the semantic of this crate's public API relative to the expiry getters.

[longsleep]

So this seems like a definition problem. Your are set to the opinion that the existing session expiry functions should deal with the session expiry configuration instead of the actual expiry. This is fine in the sense that the Expiry type is not the expiry but the "Expiry configuration" and that is stated in its doc string. So to improve, all the doc strings of the correspondig expiry should not talk about "expiry" and instead should change their docs to "expiry configuration". That would immediately make the semantics clear. For example currently for "Session.expiry" "/// Get the session expiry." should become "/// Get the session expiry configuration.".

So, no functional or semantic change there needed anymore.

This means that the problem to be able to acutally retrive a stored session expiration datetime remains unsolved. Would you be open to discuss options how to add this to this crate or not? One way would be what I suggested above (async Session.age method).