yrashk

14 ms·

91.
$5,000 for your dream project(medium.com)
16 points by yrashk 9y ago|1 comments
92.
by yrashk 10y ago
I agree, this is an importabt aspect. Our plan in PumpkinDB is to add key value association retirement, subject to defined retirement policies.
93.
by yrashk 10y ago
:D
94.
by yrashk 10y ago
Yes, I picked this style up form Pieter Hintjens
95.
by yrashk 10y ago
Well, that would have been true if we had no PumpkinScript. Then it would have been just a tiny wrapper around LMDB that we are using as a storage backend, indeed.
96.
by yrashk 10y ago
We definitely need better documentation! That's for sure. We only did a basic one just to get the basics out. As for the layout -- everything is built around btree k/v, and the original idea behind PumpkinDB is to give primitives
97.
by yrashk 10y ago
It was built as a kind of a database constructor for event sourced / journalled systems. It's design inspiration is largely stemming from MUMPS which provided a great ("oddly productive") combination of a database and a
98.
by yrashk 10y ago
Also, if this topic is interesting to anybody who's good at writing, we are very open to contributions of all kinds!
99.
by yrashk 10y ago
Doing our best, one step at a time! It's clear to me that we haven't spent enough time on documentation yet. The whole project is only 3 weeks old and our initial focus was to get a working version out with some level of documenta
100.
by yrashk 10y ago
We are definitely looking to improve the documentation. This is 0.1, after all. This project was started as a backend for a lazy event sourcing approach ( https://blog.eventsourcing.com/lazy-event-sourcing-ed7e59007... , ht
101.
by yrashk 10y ago
Some of the layering in terms of basic building blocks and higher level languages will become a standard part of PumpkinDB. For the rest, yes, it's expected that end applications or frameworks will compile higher level constructs to Pu
102.
by yrashk 10y ago
What to Submit Show HN is for something you've made that other people can play with. HN users can try it out, give you feedback, and ask questions in the thread.
103.
by yrashk 10y ago
To a certain degree, yes
104.
by yrashk 10y ago
It's a lower-level "database engine" that allows you to build different types of higher level databases based on a very simple foundation: 1) BTree-based K/V engine (which gives you an ability to iterate over lexicograph
105.
Show HN: PumpkinDB, an event sourcing database engine(pumpkindb.org)
190 points by yrashk 10y ago|48 comments
106.
O'Reilly Software Architecture Talk: Lazy Event Sourcing(youtube.com)
8 points by yrashk 10y ago|0 comments
107.
by yrashk 10y ago
This is actually how I do event sourcing in many ways. The entry happens through commands, which can do validations prior to emitting a stream of events to be journaled. I also expose a locking mechanism to commands so that they can ensure
108.
by yrashk 10y ago
Thanks for the feedback! It's not that functional programs have imperative elements or not. That's kind of besides the point. The point is that putting functional components into workflows that deal with arbitrarily mutable data i
109.
by yrashk 10y ago
I am happy to continue this conversation off-HN, perhaps Gitter? http://gitter.im/eventsourcing/eventsourcing
110.
by yrashk 10y ago
I am indeed describing CQRS, or at least the way I see it. The way I am doing is this by making my read side a combination of lightweight "code-only" domain models and heavy db-side indexing of events themselves (as opposed to dom
111.
by yrashk 10y ago
Perhaps!
112.
by yrashk 10y ago
You are quite right, event sourcing on its own is not great for read, and the "re-compute everything" (aka foldl) is problematic. CQRS solves this by producing a read-side that aggregates events into your domain. Classic event sou
113.
by yrashk 10y ago
My research into this topic has led me to lazy event sourcing so far https://blog.eventsourcing.com/lazy-event-sourcing-ed7e59007... My current view is that by eliminating or reducing the need to serialize domain objects, w
114.
by yrashk 10y ago
Yes, that's the allusion! The implication was that rather systems composed of functional programs but non-functional databases are not functional (i.e. the functional components are dwarfed by the imperative nature of mainstream databa
115.
Functional Programs Are Imperative Pumpkins(blog.eventsourcing.com)
56 points by yrashk 10y ago|72 comments
116.
There is No “User”(blog.eventsourcing.com)
2 points by yrashk 10y ago|0 comments
117.
by yrashk 10y ago
Axon Framework is an implementation of 'classic' event sourcing. This one is geared towards late domain binding.
118.
Eventsourcing for Java 0.4.0 released(es4j.eventsourcing.com)
4 points by yrashk 10y ago|2 comments
119.
by yrashk 10y ago
What exactly doesn't feel right for you?
120.
Eventsourcing and PostgreSQL(blog.eventsourcing.com)
4 points by yrashk 10y ago|2 comments

More ›