Fork me on GitHub
Drew Verlee18:01:35

i added `.clj-kondo/.cache` to /.gitignore then ran `git config --global core.excludesfile /.gitignore.` I would now expect to not see .clj-kondo/.cache files in any project, but i do. given i these files both when i run git at the command line and magit i assume the line i added to my gitignore doesn't work the way i expect.

Drew Verlee18:01:50

likely /.clj-kondo/.cache might be the answer. thanks to john in #spacemacs


double dot files huh

Richard Bowen21:01:41

Hey, say you have a dashboard and the user should be able to create 5 different custom fields to store different types of data. How do you handle creating these custom fields? Do you use a relational database? If not, what do you use?


my experience is basically non-relational things(this is painting with a broad brush since there are so many of them, a lot of which I wouldn't even call a database) are terrible, and relational databases, even the bad ones, are pretty great


so the answer to "do you use a relation database for x" is basically always going to be "yes"

Richard Bowen22:01:46

Okay cool. So it's just a matter of automating the various database operations, i.e. creating and deleting the columns created by the users?


Which database will you be considering?


letting users changing schema is almost certainly the wrong answer

Richard Bowen22:01:59

@dharrigan Most likely PostgreSQL if I was to build it but this is just a thought right now.


You may want to look into the hstore datatype on postgresql, which allows for arbitary key/value pairs


Just a thought 🙂


it will depend a lot on the specifics, but the most general thing to do (likely the worst performing resulting in the worst queries) is just go meta with it


make a schema for schemas

Richard Bowen22:01:09

@dpsutton Hmm, I see apps like which allow creating custom fields. I wonder how they do it?


a table of "tables" a table of "fields" etc

Richard Bowen22:01:49

@hiredman, could you elaborate?


a table that is just a bunch of id,name pairs, which each of those pairs is a "table"


a standard answer for this kind of thing is a table that stores

id | some-foreign-key | key        | value   | datatype | order
1  |                1 | 'color'    | 'blue'  | string   |     1
2  |                1 | 'size'     | 'large' | string   |     2
3  |                1 | 'quantity' |     '3' | integer  |     3


for one-off k/v. or make a table of keys, and a table of values if you want it a bit more structured and reusable


and a table of "columns" where each row is a triple of table id, column id, column name


and then for each type that can be stored you have tables for store that table and a reference to the row it is part of


relation databases are closed like this, they can model themselves

Richard Bowen22:01:12

@dpsutton, that's interesting, I'll explore that.


we’re giving two different types here. Mine is “they can enter 5 random key / value entries”. hiredman’s is a bit “they can define their schema and use that”. If you want to just save 5 random entries per thing, and they can be 5 different things across all of the pages, then mine is fine. If you want some admin to add 5 questions that are the same across all things, hiredman’s version is necessary


yeah, and what I describe is the most general case, and likely going to be the worst for performance, etc


everything becomes complicated joins


so if something like a key/value table works then use that, or checkout postgres's json storage stuff (I use postgres for personal projects, and haven't messed with the json stuff)


@rbowen modeling 'fields' in the database is pretty common The key as to whether it's a good idea is scale. For example if you're allowing users to create one-off forms (like Typeform does), probably those forms will be filled less than 1000 times. So it all fits in memory and 'queries' can be implemented in Clojure or what have you.