@credulous >Error loading cider.nrepl.middleware.test: java.lang.RuntimeException: Invalid token: ::clojure.test/once-fixtures, compiling:(cider/nrepl/middleware/test.clj:103:57)
::clojure.test/once-fixtures
try removing one colon
Wait
that's cider code
and it looks like this was fixed
What version of Cider are you running?
https://github.com/clojure-emacs/cider/issues/2081#issuecomment-365299752
Hope some of this information helps
Right. In my original project the Luminus setup was forcing cider-nrepl 0.10.1
I wasn’t sure how - it’s not in the project.clj anywhere, and it’s listed as a top-level dependency when I run lein deps :tree
So that’s the way it is in that vanilla test project I pasted above
But in my project I added [cider/cider-nrepl “0.18.0”] to the project dependencies, which overrode whatever was insisting on 0.10.1
These are the deps on that project:
(output from lein deps :tree
)
and I still get an error, but a different one.
How do you extend the session timeout in the default luminus template? the ring-ttl-session docs suggest there could be a performance hit. Would ignoring it entirely be a better option?
I'm using reagent and secretary on the frontend. Would a forced re-direct re-new the session?
@jcb if you're using immutant (default http server) it leverages jboss sessions and those are quite fast
The ring-ttl-session is mostly recommend for other servers such as jetty or http-kit, and the performance with it is still quite decent
The session is managed by a cookie, so if you wanted to renew it, you'd want to clear the cookie on the client, or remove the session on the server explicitly, the latter is the recommended approach
I am using immutant, it's pretty much the generated scaffold other than an asset path tweak so my wrap base looks like this -
(defn wrap-base [handler] (if-let [asset-path (:asset-path env)] (-> ((:middleware defaults) handler) wrap-webjars wrap-flash (wrap-session {:cookie-attrs {:http-only true}}) (wrap-defaults (-> site-defaults (assoc-in [:static :files] asset-path) (assoc-in [:security :anti-forgery] false) (dissoc :session))) wrap-internal-error)) )
I guess my use is a bit of an edge case, it's for a set of kiosked locally hosted displays so the session expiry messes with the communication with the database
and there is no way for the user to refresh the page
thanks for your explanation @yogthos but I'm unsure how to proceed
yeah so you are using the immutant session already, and you shouldn't see any performance problems there
could you explain the workflow a bit more, how is the session lifecycle supposed to work?
Hi, I hate to repeat myself, and if my problem is unsolvable I’ll move on. I’ve created an app with +mysql, and only modified the database url - i.e. I haven’t touched the default migration. When I run lein run migrate
I get an error in migratus saying that the query is empty:
Migratus has created and populated the schema_migrations table, so I think the db and url are correct.
Also, when I cut-and-paste the command above into the mysql console, it works fine
I'm getting 403 returns from my post requests after about 30 minutes of inactivity, and I'm not sure how to stop this from happening
the easiest option would be to switch to using a cookie based session without expiry
in that scenario you wouldn't have a server-side memory session at all, and all the session information would be tracked by the cookie, there are examples in the official Ring docs here https://github.com/ring-clojure/ring/wiki/Sessions
how would I explicitly remove the session?
hi @credulous I was having weird problems with migratus yesterday too. Have you tried deleting the schema_migrations table or rollback?
I had to generate new migrations and start again but I've been fine with subsequent migrations
Thanks @jcb, yeah I’ve actually been dropping and recreating the database each time.
I'm using sqlite so I'm not sure what if those ssl warnings are significant
I’ve gotten rid of the warnings but the problem remains. I turned on trace debugging and migratus.migration.sql has the query right to the bitter end. But the call to clojure.java.jdbc/db-do-commands fails.
Feeling pretty idiotic - on my third day trying to get a basic fullstack app going. Clojure the language is awesome but I’m finding the dev environment very difficult.
I just had this same experience! I was doing too much. I got mine working by letting the templates do everything and learning more about the user namespace and my new favorite command (keys (ns-publics 'user))
http://llsouder.blogspot.com/2018/10/spacemacs-cider-figwheel_42.html
Once you get things going, it's insanely nice. I agree that getting started is frustrating, though. Even once I got things working it took me some time to figure out how to architect the application without a more opinionated framework