haf / Documently

Domain Driven Design with CQRS, Event Sourcing, MassTransit, RavenDB, RabbitMQ and C# and F#.
http://architecture.jayway.com
218 stars 54 forks source link

EventStoreRepository not saving to RavenDb #20

Closed wayne-o closed 12 years ago

wayne-o commented 12 years ago

EventStoreRepository doesn't seem to be commiting stuff to the DB?

Is this a WIP or have I managed to misconfig something?

wayne-o commented 12 years ago

Is the only diff between the commondomain one and this one the fact that we are now using NewId?

haf commented 12 years ago

Right, but NewId is converted to a Guid just before being saved into the event store.

What is the order of procedure calls that you are doing that shows the problem? Save from WPF client, then relocating, then having CMD handler fail because of relocation requires existing user?

Are you on develop or master?

wayne-o commented 12 years ago

Actually just running the app doesn't save either. On May 1, 2012 7:56 PM, "Henrik Feldt" < reply@reply.github.com> wrote:

Right, but NewId is converted to a Guid just before being saved into the event store.

What is the order of procedure calls that you are doing that shows the problem? Save from WPF client, then relocating, then having CMD handler fail because of relocation requires existing user?

Are you on develop or master?


Reply to this email directly or view it on GitHub: https://github.com/haf/Documently/issues/20#issuecomment-5445338

wayne-o commented 12 years ago

This is develop On May 1, 2012 7:57 PM, "Wayne Douglas" wayne@prjatk.com wrote:

Actually just running the app doesn't save either. On May 1, 2012 7:56 PM, "Henrik Feldt" < reply@reply.github.com> wrote:

Right, but NewId is converted to a Guid just before being saved into the event store.

What is the order of procedure calls that you are doing that shows the problem? Save from WPF client, then relocating, then having CMD handler fail because of relocation requires existing user?

Are you on develop or master?


Reply to this email directly or view it on GitHub: https://github.com/haf/Documently/issues/20#issuecomment-5445338

haf commented 12 years ago

Develop is a bit untested at this moment, but I haven't changed anything particular with EventStore/RavenDB... Is EventStore calling RavenDB? Is RavenDB up? Is the repository being called?

wayne-o commented 12 years ago

I think it's because this:

[UsedImplicitly] internal void Apply(Registered evt) { Id = evt.AggregateId; }

is never called - so it's complaining about non unique commits

On Tue, May 1, 2012 at 7:59 PM, Henrik Feldt < reply@reply.github.com

wrote:

Develop is a bit untested at this moment, but I haven't changed anything particular with EventStore/RavenDB... Is EventStore calling RavenDB? Is RavenDB up? Is the repository being called?


Reply to this email directly or view it on GitHub: https://github.com/haf/Documently/issues/20#issuecomment-5445387

wayne-o commented 12 years ago

ok

on the documently code, if i do this in CreateHandler:

public void Consume(IConsumeContext context) { try { DocumentCollection collection = DocumentCollection.CreateNew(context.Message.Name); DomainRepository repository = this._reposistory(); repository.Save(collection, new NewId(context.MessageId), context.GetHeaders()); } catch (Exception exc) { _logger.Error(exc); } }

I get the following stack from the exception...

at lambda_method(Closure , Created , Object ) at Magnum.Binding.ObjectPropertyBinder1.SetValue(T instance, Object value) in d:\Builds\MassTransit-Magnum\src\Magnum\Binding\ObjectPropertyBinder.cs:line 43 at Magnum.Binding.FastObjectBinder1.<>cDisplayClass1.b0(ObjectPropertyBinder1 property) in d:\Builds\MassTransit-Magnum\src\Magnum\Binding\FastObjectBinder.cs:line 36 at Magnum.Extensions.ExtensionsToEnumerable.Each[T](IEnumerable1 collection, Action1 callback) in d:\Builds\MassTransit-Magnum\src\Magnum\Extensions\ExtensionsToEnumerable.cs:line 32 at Magnum.Binding.FastObjectBinder1.Bind(BinderContext context) in d:\Builds\MassTransit-Magnum\src\Magnum\Binding\FastObjectBinder.cs:line 32 at Magnum.Binding.InstanceBinderContext.Bind(Type type) in d:\Builds\MassTransit-Magnum\src\Magnum\Binding\InstanceBinderContext.cs:line 109 at Magnum.Binding.FastModelBinder.Bind(Type type, ModelBinderContext context) in d:\Builds\MassTransit-Magnum\src\Magnum\Binding\FastModelBinder.cs:line 25 at Magnum.Reflection.InterfaceImplementationInitializer.InitializeFromDictionary(Type objectType, IDictionary2 values) in d:\Builds\MassTransit-Magnum\src\Magnum\Reflection\InterfaceImplementationInitializer.cs:line 30 at Magnum.Reflection.InterfaceImplementationExtensions.InitializeProxy(Type interfaceType, IDictionary2 values) in d:\Builds\MassTransit-Magnum\src\Magnum\Reflection\InterfaceImplementationExtensions.cs:line 35 at Magnum.Reflection.InterfaceImplementationExtensions.InitializeProxy(Type interfaceType, Object initializer) in d:\Builds\MassTransit-Magnum\src\Magnum\Reflection\InterfaceImplementationExtensions.cs:line 28 at Magnum.Reflection.InterfaceImplementationExtensions.InitializeProxyT in d:\Builds\MassTransit-Magnum\src\Magnum\Reflection\InterfaceImplementationExtensions.cs:line 41 at Documently.Domain.AggregateRootEx.Raise[TAr,T](TAr ar, Object anonymousDictionary) in C:\Users\Wayne Douglas\Dev\Scratch\Documently\src\Documently.Domain\AggregateRootEx.cs:line 37 at Documently.Domain.DocumentCollection..ctor(String collectionName) in C:\Users\Wayne Douglas\Dev\Scratch\Documently\src\Documently.Domain\DocCollection\DocumentCollection.cs:line 20 at Documently.Domain.DocumentCollection.CreateNew(String collectionName) in C:\Users\Wayne Douglas\Dev\Scratch\Documently\src\Documently.Domain\DocCollection\DocumentCollection.cs:line 37 at Documently.Domain.CommandHandlers.ForDocCollection.CreateHandler.Consume(IConsumeContext`1 context) in C:\Users\Wayne Douglas\Dev\Scratch\Documently\src\Documently.Domain.CommandHandlers\ForDocCollection\CreateHandler.cs:line 67

On Tue, May 1, 2012 at 8:12 PM, Wayne Douglas wayne@prjatk.com wrote:

I think it's because this:

[UsedImplicitly] internal void Apply(Registered evt) { Id = evt.AggregateId; }

is never called - so it's complaining about non unique commits

On Tue, May 1, 2012 at 7:59 PM, Henrik Feldt < reply@reply.github.com

wrote:

Develop is a bit untested at this moment, but I haven't changed anything particular with EventStore/RavenDB... Is EventStore calling RavenDB? Is RavenDB up? Is the repository being called?


Reply to this email directly or view it on GitHub: https://github.com/haf/Documently/issues/20#issuecomment-5445387

haf commented 12 years ago

Right; that's what GH-19 fixes. We're on it ;).

wayne-o commented 12 years ago

What I don't understand is that my AR is not able to save because it doesn't have a unique Id - it has a blank guid because the public void Apply(IUserCreated @event) is only ever called in the GetById method in the DomainRepository - so this is after it has been saved - which can't happen because....

Shouldn't the events be applied before saving?

haf commented 12 years ago

They should indeed be applied before saving.

wayne-o commented 12 years ago

Where does that happen? On May 2, 2012 8:22 AM, "Henrik Feldt" < reply@reply.github.com> wrote:

They should indeed be applied before saving.


Reply to this email directly or view it on GitHub: https://github.com/haf/Documently/issues/20#issuecomment-5455471

haf commented 12 years ago

@wayne-o: develop is shaping up. I like that you comment and prod me into making the sample better!

wayne-o commented 12 years ago

haha

i'm learning a lot from this project

way way more than any other code samples out there - so thank you :)

On Wed, May 2, 2012 at 9:14 AM, Henrik Feldt < reply@reply.github.com

wrote:

@wayne-o: develop is shaping up. I like that you comment and prod me into making the sample better!


Reply to this email directly or view it on GitHub: https://github.com/haf/Documently/issues/20#issuecomment-5456083