This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aatree (257)
- # admin-announcements (13)
- # beginners (3)
- # boot (327)
- # cider (2)
- # cljs-dev (1)
- # clojure (127)
- # clojure-art (72)
- # clojure-russia (273)
- # clojure-sg (1)
- # clojurescript (39)
- # cursive (8)
- # datomic (6)
- # editors (2)
- # emacs (4)
- # hoplon (261)
- # immutant (2)
- # ldnclj (15)
- # liberator (10)
- # luminus (1)
- # off-topic (8)
- # om (9)
- # parinfer (1)
- # re-frame (11)
- # reagent (2)
- # yada (9)
You want to look at yearling. this is the database that builds over virtual aatree structures. An OODBMS for EDN.
Using the Datomic analogy, I want the hoplon clients to be the peers with their own caches and 80% of the database code running in the client. Unfortunately, it is the 80% that has not yet been converted from java.
it seems to me that we use relational databases to store our application state only because storing only facts in sorted sets achieves the laziness, like you don't need to fetch an entire tree or sequence of things from storage to perform a query
but in all other ways relational databases are terrible, because you need to build your trees and maps and whatnot via joins
My db is very close to datomic, with the same indexes and everything. (my java db, not what I have in clojure so far)
Datomic makes it difficult to deal with changes over time, though I think it can still be done.
I'm doing the reverse. First implement virtual clojure data. Then add support for changes over time. Then build the indexes on top of that.
This gives me a rich mix. I can have some things that are not tracked over time, for example.
Now I am very excited about doing the om next thing, but with haplon and my own db. And put the application code in the browser!
right now the thing that takes our dev time is incidental complexity involved with shuffling things in and out of memory in the client, making ajax requests etc
I did access control. So users can have a private part of the database for managing their apps.
And even updates on the server would be generic and access controlled. So it is really all on the mobile. the logic anyway. most of the logic is data that can be moved anywhere.
Needless to say, I need to build a team to do all this. I am just happy that clojure is denser than java.
aatree is missing a layer--the entitys/attributes/values and indexes are all built on top.
With hoplon methinks I need to add subscriptions to notifications soon. To allow clients to maintain a cache. 😄
i mean you can, but you need to make a call to the backend to fetch the part of the tree where it lives
Once we have a reasonable team, we can fork out in different directions. With developers contributing to multiple forks. One size, after all, does not fit all. I think that is necessary to achieve real scale.
My basic design for the dbs is composits of bags. keeps things flexible. A VERY open architecture!
Documents, on the other hand, are allowed to be a bit more abstract so they do not need to be constantly updated.
but don't let it get like lein--which has more issues than the next 100 most popular projects combined.
i don't like the things that generate html because while it might look fancy, it's harder to version with the code
with javadocs I always turned off the timestamps so versioning would be more reasonable.
I wasted a lot of space in the past as I included a copy of the javadocs in each release.
so lets close the loop and give the client in the browser access to the virtual data structures.
a way to form abstractions around distributed systems problems you encounter in the client
by expressing them as a combination of datastructures stored on some persisted storage and the state machines that mediate access and modification of them
I did some distributed stuff. Once you get the basics down, it is pretty simple. Just a tad subtle. Quarm logic on the bottom is key.
i have this feeling that there are a relatively small number of state machines that can describe any kind of distributed system interaction
what i'm specifically interested in is developing a set of abstractions that clearly define the tradeoffs involved
better to say that there are a relatively small number of state machines that can be used to describe any kind of distributed interaction. I.E. You only need a few.
the key thing is to clearly delinieate the tradeoffs and ensure correctness within the constraints of those
But for the foreseeable future I plan to focus on plain old client server. Too much stuff left to migrate from Java.
I think there is a place in my virtual aatree structure where I can generate change notifications.
I'm gona call it a night. I must say, these discussions keep getting more interesting!