Clojurians Log v2

Why this Keechma app is not able to run? https://gist.github.com/ahmed1hsn/7351ae6e1edaa64b9109ed19c8776af6

does this even compile ? get-in lacks a parameter in params method of your controller

there is a lein template to make a basic keechma app, though i never used that

the edb schema, although you don't use it yet is wrong too

as far as i understand it, for each "table" you define the id and relations

here is one i made for testing

no need to specify other fields than trhose required for normalisation

for now your params method shoudl just return true

you can use it to decide if you want the controller running in this context, by returning true or false

here is the routes for this counters test app i made

i wanted to always have a :page in my route

with counters being the default one

@carkh Thanks.

What defentitydb does exactly?

i creates a bunch of accessor functions for the tables you defined with the schema

https://github.com/keechma/keechma-toolbox/blob/master/src/clj/keechma/toolbox/edb.clj

This is great, so you don't have to mention Schema everytime.

means you can change the schema and have minimal impact on your code

on the rest of your code i mean

though the fact that it's normalized already does that

It opens many cool possibilities, such as you can have different Schemas in their namespaces, you can make as many DB's you want with with their respective Schemas per DB. Although you don't need it most of the time.

Perks of not having global application state.

mhh possibly, though we're really using this to facilitate data loading

so you'll need to somehow bring it all together when instanciating your app

oh but yes for different apps yes that can be done

Like example given on Keechma blog where main application only starts when user session is present.

In this case you can have different schema'd DBs for both two apps.

yes

depends on your use case

How does it help in facilitating data loading?

the data loader uses your schema ot distribute the data it downloads from the server(s) into those tables you defined

normalising it

in my test app, i had several counters which each had a collection of clicks (with date of the click)

they were downloaded from the server as [{:id 1 :name "counter1" :clicks [{:id 1 :timestamp "..."}]}]

and were automatically normalised so that clicks ended in their own table

that's the dalaloader that does this

well i think the entitydb must do the normalising, but they work hand in hand

Entitydb seems more structured than re-frame atom due to schema.

yes, but you still can use the rest of the database as you would in re-frame

so you have the best of both worlds here

some data just won't be a natural fit for normalization