you mean 3.6.0-RC5, I guess?

I do…

Yes. That is the correct query

but there’s more to it…someone has to trigger a load to load that user into normalized form…e.g. someplace your code has to actually run a df/load! on that ident/query combo

(df/load! app [:user/id id] (rc/nc [:user/id :user/name])) for example

but if you actually mean “session” in the cookie sense, then the answer is more speculative.

in that case where does the-current-user come from?

yeah I have a query in my root {:root/current-session (comp/get-query session/Session)}

and the current user will be in [:root/current-session :user/id]

ok, so if you’re already doing that, and the Session component has normalized the user, then your component query shown will work

did you also read https://book.fulcrologic.com/#_a_warning_about_ident_and_link_queries

What is your Session component’s query???

yes that's the path I'm trying to follow

is should be more like [{:session/user (comp/get-query User}] , where you have a User component that will normalize the user

(defsc Session
  "Session representation. Used primarily for server queries. On-screen representation happens in Login component."
  [_ _]
  {:query [:user/id
           :user/username
           :session/valid?]
   :ident (fn [] [:component/id :user-session])
   :pre-merge     (fn [{:keys [data-tree]}]
                    (merge {:session/valid? false :user/id nil}
                           data-tree))
   :initial-state {:session/valid? false :user/id nil}})

your ident should be :user/id (not a fn)

that way the user info gets normalized

OR, you can use the link query {[:component/id :user-session] [:user/username]}

link queries just point to things in your database, and ident puts them there…

my understanding was that with the fn ident Session would be a singleton

so up to you…if you want to do live user-switching, then the “current session” is the value held by :root/current-session…which can be a changing ident pointing to user data, which can be normalized.

But the core answer to your question is the link query (ident-based join). You just have to decide how you want to represent that data, and link to it.

I don't really mind if the current user is not normalized, like in your video on sessions https://www.youtube.com/watch?v=oQpmKWBm9HE&list=PLVi9lDx-4C_T7jkihlQflyqGqU4xVtsfi&index=15

you can also do {[:root/current-session '_] [:user/username]}

I don’t care either 😄

It’s your application

I’m just telling you how to exactly do your very initial question (literally). OR telling you to modify what you do based on how you actually laid out the data.

The answer is “link query”. The details from there depend on your app.

Thanks I'm going to go through the link queries chapter again

and remember that queries always auto-denormalize…so even if your session is normalized that last link query works…so it is probably more what you want

{[:root/current-session '_] [:user/username]}

Not exactly. The fo/default-value is used in the UISM of the form, when CREATING a new entity, to pre-fill that value into the form…but the requirement there is that the attribute in question is actually on the form. If you want a value to be auto-filled full-stack, then you would need to augment the save middleware to do so.

There are (at least) two concerns when talking about “default values”, and they need to be separate: 1. Convenience: pre-filling a field on a form that is likely (e.g. timezone that you detected from a browser) 2. To ensure that the value exists in the database for schema/consistency purposes (often requires a calculation, and may …e.g. who owns this new entity I’m saving? Answer: the person in my current session that talked to me.) The former is the purpose of fo/default-value, which is why it is a form option and not a database adapter option (or attribute option). The latter is pretty wide-open in terms of what has to happen (how do you calculate the value? Where are your sessions? What are your security rules?), and is left to the save middleware.

Of course you can try to leverage fo/default-value in your save middleware if it makes sense to you, but I don’t want to conflate the meanings.

That absolutely makes, thanks a lot!