Fork me on GitHub

@jfntn do not use datomic as a session store for logged out users. you do not want 100s of 1000s of google bot and phpmyadmin and sql injection attacks cluttering up your database 🙂 trust me on this. i'm busy crafting a codebase to rebuild our database from scratch partly because we have so much of this junk. we settled on using cookie storage for sessions, to store a uuid, and we create a session entity in datomic with that uuid when the user signs in, to capture ua and ip, and to link activity to a session. we use the uuid as a value directly for the things where we need to record the user when signed out. this works out much better. happy to answer questions if you have 'em


@marshall please consider allowing multiple Download Keys for Datomic Pro. having one active at a time means that we have to reset it and very quickly go and update all the places it's used, or e.g. builds break. Supporting multiple gives us a grace period to update things without breakage. thanks!


seconding @robert-stuttaford's suggestion: use cookie storage for sessions wherever possible and for as much data as possible. Session storage used to be one of the most important causes of database slowness, and an append-only db is really not the best place to store what is essentially ephemeral data


@robert-stuttaford I’ll register the request with the team!


If Cognitect are updating the website, they could also update the 'Project Setup' section so it references current version of the product.


@robert-stuttaford great advice thanks. So if I understand correctly the flow is: sign-in -> tx session -> store session/key (uuid) in cookies. Then on the next request you’d lookup the session/key from the cookies (probably indexed?) and get a hold of the user through a session/user ref?


first visit: write session uuid to cookie. middleware does this. maybe use said uuid as a normal value in datomic transactions.. e.g. :cart/guest-session-uuid visitor signs in: create session entity, using uuid as its unique identifier. capture additional metadata, such as ip and user-agent. link session entity to user entity. subsequent visits from signed in user: middleware uses uuid from cookie to find session, and uses session to find user. @jfntn 🙂


@robert-stuttaford gotcha, makes sense to create a cookies-only session then escalate it to an entity on login, that’s great advice thank you!


Trying to make sense of this error:

datomic.impl.Exceptions$IllegalStateExceptionInfo: :db.error/unique-conflict Unique conflict: :email/address, value: N/A already held by: <eid elided> asserted for: <eid elided>
    data: {:db/error :db.error/unique-conflict}


The N/A is what's tripping me up.


looks like it’s saying the string “N/A” is set for an EID in the db


I’m assuming :email/address is set to db/unique value


It is indeed.


Let me check if we have an :email/address" set to "N/A".


you should be able to pull the first EID


Is there a way to invalidate the cache for a connection?


@bmays by invalidate do you mean to delete or reset cache entries? Are you referring to the object cache or memcached?


@jaret — the object cache. I’m hoping to empty/reset the cache. I’m noticing entities in the cache after restoring the database to a previous version.


@bmays you absolutely should reboot any peers after a restore

Ben Kamphaus20:09:39

Not entities in the way it sounds like you’re thinking — Datomic caches segments and segments are immutable. But also as indicated here you should run restore with all processes down:


@bmays as Robert indicated you can restart jvm to clear the object cache


@robert-stuttaford I’m trying to avoid impacting another database being served by the same process. We have multiple databases, some which are periodically ingesting large amounts of data (attempting to use restore to avoid using the transactor).


My goal is really to set a database state without impacting the transactor’s performance — attempting to use the restore-db function to do that.