I can't use the dependency "com.eventsourcing:eventsourcing-inmem:0.3.1" because it is missing on the Bintray Maven repository [1].

Work-around: Deploy the dependency to a local maven repository.

[1] http://dl.bintray.com/eventsourcing/maven/com/eventsourcing/

In any system the schema of commands and events will naturally evolve. While this is typically not a problem when using MemoryJournal (the data will not survive through restarts), it is an issue with persistent journals (MVStoreJournal and others).

Every persistent journal will need to print out the discrepancies found between entities available in the journal and in runtime. Using layout's hash we can easily detect which entities in the journal are no longer covered by the code at hand.

The report should look like this:

Found 1 unrecognized entity:

    d395f099078879b005797edf7ef37f83a673bb3582056490655984d3d5b18cf8 (234 records)

This reporter should not try to attempt facilitating schema migrations in any way, it should be just a reporter.

It would be great if some meta information can be stored every time the journal is used. This way, the report can be much more readable:

Found 1 unrecognized entity:

    com.foo.bar.events.UserLoggedIn (234 records) # d395f099078879b005797edf7ef37f83a673bb3582056490655984d3d5b18cf8

Even better if the layout can be saved, too:

Found 1 unrecognized entity:

    com.foo.bar.events.UserLoggedIn (234 records) # d395f099078879b005797edf7ef37f83a673bb3582056490655984d3d5b18cf8
     login: String

Upon index initialization, index has no idea if the object store's data has been indexed.

Solution: in PostgreSQL-backed journal, assign sequential IDs to entities and introduce the use of NotSeenBy query option to avoid reindexing

(Since the timestamp is not really comparable as is, it needs to be transparently re-encoded to a comparable value in order to work)

eventsourcing=# \d+ index_v1_9c22ea3e2733ba23f1e23c8577698827575a4457_navigable;
                   Table "public.index_v1_9c22ea3e2733ba23f1e23c8577698827575a4457_navigable"
 Column |                        Type                        | Modifiers | Storage  | Stats target | Description
--------+----------------------------------------------------+-----------+----------+--------------+-------------
 key    | layout_v1_c47d416193cba63554e5a69ca701973bc3e44172 |           | extended |              |
 object | uuid                                               |           | plain    |              |
Indexes:
    "index_v1_9c22ea3e2733ba23f1e23c8577698827575a4457_navigable_key" btree (key)
    "index_v1_9c22ea3e2733ba23f1e23c8577698827575a4457_navigable_obj" btree (object)

eventsourcing=# \d+ layout_v1_c47d416193cba63554e5a69ca701973bc3e44172
Composite type "public.layout_v1_c47d416193cba63554e5a69ca701973bc3e44172"
     Column     |  Type  | Modifiers | Storage | Description
----------------+--------+-----------+---------+-------------
 logicalCounter | bigint |           | plain   |
 logicalTime    | bigint |           | plain   |

Once a query is executed, it is impossible to know when the data queried against has changed, leaving us to requery at some time intervals.

Solution: implement a QuerySubscriber that would listen to all entities and notify its own subscribers that a particular query's set has changed.

It is rather simplistic for now, and I am not quite sure it is suitable for all scenarios, but we can address this later, and if it doesn't work out, remove it. One of the areas for improvement is to implement query-and-subscribe.

I would like to propose to use http://docs.sonarqube.org/display/HOME/SonarQube+Platform for code analysis. For IntelliJ - Sonar Lint http://www.sonarlint.org/intellij/. It can be done as part of CI pipeline and will improve quality of the code.

If Command#events takes long time to complete (for example, making external API calls), the entire queue of commands will be blocked, because command processing is a single-thread process (originally, to avoid the complexities associated with multithread access to journal, indexing, etc.). This also holds true for massive event streams.

Solution: remove Disruptor and use a worker pool

Closes #145

Solution: make repository generate EntityLayoutIntroduced on demand

This change is fairly massive for a number of reasons. Besides adding generation of EntityLayoutIntroduced (RFC 8/EMT), the changes are:

1. Repository implementation has been split into eventsourcing-repository module to allow it to have a non-circular dependency on eventsourcing-migrations
2. RepositoryImpl has been renamed to StandardRepository for consistency and Repository.create() has been replaced with new StandardRepository()
3. Fixed PostgreSQL connection leaks, closes #90
4. Fixed PostgreSQL Optional serialization and deserialization
5. Fixed composite type treatment with lists inside

This is most likely happening due to https://github.com/npgall/cqengine/issues/74 — that said, we do have a workaround for this — if the iterator was actually finished, it should close.

It sounds like a callback, while in fact it is a function that takes a state from an EventStream and produces a "result"

Solution: rename it to #result()

Also, change the order of type parameters for Command from Result, State to State, Result to follow the order of their dependency.

Also, the requirement for entities and objects to have a default empty constructors is onerous.

Solution: make layouts constructor+getters driven

Instead of defining layouts through a full set of accessors, a single constructor drives the layout. Therefore a use of the builder pattern and immutable (final) properties is now advised.

This solution changes some APIs:

1. new Layout<>(klass) is deprecated in favour of Layout.forClass(klass)

At this moment, Min/Max queries are limited to finding the smallest or largest value of a particular attribute globally across an entity. Which means you can tell "what's the latest order" but not "what's the latest order for this person". IsLatestEntity/LatestAssociatedEntryQuery are currently being used to address this type of need, but they are very slow and cumbersome. Min/Max has been already optimized for PostgreSQL storage.

It would have been great if it was possible to fit this type query within Min/Max as an option:

// Find the last order for user with id=<id>
max(Order.TIMESTAMP, equal(Order.USER_ID, id))
// Find all last orders for all users
max(Order.TIMESTAMP, Order.USER_ID)

(Or something similar)

PostgreSQL-backed journal & indices will create necessary tables and types without consideration for others — meaning there might be a conflict and two nodes might attempt to do the same thing at the same time.

Proposed solution: ensure these storages are locking these initialization routines. PostgreSQL advisory locks can be used to easily accomplish this.

In Kotlin, as is a reserved keyword, and leads to this:

@JvmField var X = SimpleIndex.`as` { o: TestEntity -> o.x }

as opposed to

@JvmField var X = SimpleIndex.as { o: TestEntity -> o.x }

which is far from great

And we're using the same name for es4j for naming maven artifacts and package names, which might make it more difficult to assign proper naming to other solutions.

Proposed solution 1: rename com.eventsourcing:eventsourcing-X maven artifacts to com.eventsourcing:es4j-X and packages com.eventsourcing.* to com.eventsourcing.es4j.*

Proposed solution 2: rename com.eventsourcing:eventsourcing-X maven artifacts to org.es4j:es4j-X and packages com.eventsourcing.* to org.es4j.*

Proposed solution 3: rename com.eventsourcing:eventsourcing-X maven artifacts to com.eventsourcing:es4j-X and packages com.eventsourcing.* to org.es4j.*

Proposed solution 4: find a completely different name for es4j

It is, however, still very desirable to detect parameter names. @ParameterName is one possible workaround, but it is a bit verbose.

Proposed solution: In some cases, it might be possible to use @java.beans.ConstructorProperties. Nice thing is that (for example) Lombok generates it automatically.