[jira] [Resolved] (ZEST-139) Discard dangling UnitOfWorks on passivation

[ https://issues.apache.org/jira/browse/ZEST-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Merlin resolved ZEST-139. -- Resolution: Won't Fix The thing is, dangling UoWs can be associated with several threads, not only the

[jira] [Commented] (ZEST-122) Use parameter names to build better error messages on null barrier faults

[ https://issues.apache.org/jira/browse/ZEST-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15360574#comment-15360574 ] Paul Merlin commented on ZEST-122: -- It turns out that parameter names are not included in bytecode by

[jira] [Commented] (ZEST-121) Use parameter names to build better error messages on constraints violations

[ https://issues.apache.org/jira/browse/ZEST-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15360573#comment-15360573 ] Paul Merlin commented on ZEST-121: -- It turns out that parameter names are not included in bytecode by

Re: Zest QuickStart??

Yeah, I have not put in enough care in this, a. Yes, I agree that external types should be easy to add. GitHub pull is one good mechanism. b. I have not spent a single second on anything but Mac OSX. Not sure what you are on. c. As usual, feel free to improve. I don't think I have anything in

Re: ValueSerialization mystery

On Sun, Jul 3, 2016 at 10:33 PM, Paul Merlin wrote: > > IRRC, the issue with "_type" is polymorphism in deserialization. > For example, if you need to deserialize some Property that > contains either a Car, a Bus or a Motocycle you need to read "_type" early. > This is of

Re: ValueSerialization mystery

Niclas Hedhman a écrit : > I am about halfway through a new implementation that only has the the > "token"-level parsing (I think you call that "push"). It seems to simplify > the design, although a lot more code for token checks, but I think it is > the right thing to do. Yep, push/token VS.

Re: ValueSerialization mystery

I am about halfway through a new implementation that only has the the "token"-level parsing (I think you call that "push"). It seems to simplify the design, although a lot more code for token checks, but I think it is the right thing to do. In this, it doesn't seem to hard to support both Map

[jira] [Commented] (ZEST-138) org.json ValueSerialization of Serializable fail when out of JSON sequence

[ https://issues.apache.org/jira/browse/ZEST-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15360552#comment-15360552 ] Paul Merlin commented on ZEST-138: -- org.json ValueSerialization does not support "out of sequence values".

Re: Philosophy behind Identity

When I think back at my discussions with Rickard F2F, Event Sourcing in reality wants to record the "cause" and not the "effect", i.e. the business level method that happens is to be recorded and the "effect" of that is replayed through the model each time the entity is retrieved (in case the

[jira] [Commented] (ZEST-149) Migrate documentation to AsciiDoctor

[ https://issues.apache.org/jira/browse/ZEST-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15360549#comment-15360549 ] Paul Merlin commented on ZEST-149: -- One issue with asciidoctor is that cross-references in chunked HTML

Re: ValueSerialization mystery

Niclas Hedhman a écrit : > Paul, > What is the difference between the two Map deserialization methods in > ValueDeserializationAdapter? > > One is parsing using tokens, and the other seems to be using JsonNode. One > is has keyDeserializer in the arguments and the other don't use that. I am > very

Re: ?????? ?????? Large Scale Entity Store Database?

zhuangmz08 a ??crit : > Hi, > I've trying out elasticsearch index/query engine. However, I meet this > exception: MaxBytesLengthExceededException[bytes can be at most 32766 in > length; got 79504] > I found an answer in stackoverflow >

Re: Philosophy behind Identity

Paul Merlin a écrit : > Another non-core approach we could use for Event Sourcing is to > implement StateChangeListeners that generate and store state diffs (with > e.g. json-patch). The same could be done for Timeseries, possibly with > property/association value granularity. This would still

Re: Philosophy behind Identity

Niclas Hedhman a écrit : > On Sat, Jul 2, 2016 at 11:18 PM, Paul Merlin wrote: >> On 2016-06-22 14:45 (+0200), Niclas Hedhman wrote: >>> Entity == "Identity with Value property", >>> versus DTO == "Value with Identity property" >> It makes sense in the DDD mindset but blurs the