Queries: do they have to be defined in a command?

[TheColonel2688]

Do queries have to be defined in a command? Or can they be done dynamically?

Are you cause planning on fleshing out the documentation any more in the near future?

[rofr]

Do queries have to be defined in a command? Or can they be done dynamically?

Queries inherit Query and commands inherit Command. These are very different things as commands are persisted and used to rebuild the state during startup. Commands make a change to the model, that is their purpose. Of course they can also return something.

So normally you create commands and queries for each operation but there is a more elegant way using a proxy.

A proxy is an object that has the same interface as your model. Calls to public methods are intercepted by the memstate engine. Void methods are treated as commands and methods that return something are treated as queries. You can find more in the docs.

I won't be doing anything with the docs at least until the redesign has settled. But given this type of question you can learn tons from the docs even if the APIs are slightly different. I understand this can be annoying when trying something out but ask here if you get stuck and we'll try to help you out.

[rofr]

Yes and no. The docs are at https://memstate.io/docs/core-1.0/ but is basically a copy of the OrigoDB docs with some modifications.

[TheColonel2688]

Oh, Is there a link to that somewhere I missed? All I had seen was the memstate quickstart in github readme, and then the OrigoDB docs.

[TheColonel2688]

Looks like the built-in Relational Model is missing from the Memstate docs, it is still present? just not documented?

[TheColonel2688]

I'm coming from experience with MS Entity Framework. So I am trying to figure out how I would go about doing the same things I can do in EF when using a SQL provider. I just want something in memory, that behaves the same. That is ultimately what I am after.

For example, in EF if I have Parts and Product entities, and a Many to One relationship, on those. Then if I add a brand new part to a product, it will automatically get added to the parts list.

Deletes are a trickier deal, and I don't remember exactly how that works, it's been a couple of years since I used EF a lot.

As for Memstate: I seem to have found the Entity base class. But I don't see anything with the basic CRUD operations.

[TheColonel2688]

I found the source for the Relational Model at https://github.com/DevrexLabs/memstate/tree/master/src/Memstate.Core/Models/Relational

So I am trying to figure out how to use it by looking at the source. I think most of my questions still stand though

[rofr]

I just want something in memory, that behaves the same.

Why mimick the behavior of an object-relational mapper (ORM) when there is no mapping and moving data back and forth between the application and the database?

With an ORM you typically

1. Read some data from the database and create objects that represent this data
2. Make changes to the objects
3. Detect and translate those changes back to the database.

This is actually very complicated and difficult to do correctly. It imposes constraints on you as a developer with contrived code and lots of traps to fall into. In code this looks like:

// Entity Framework example
var ctx = new MyDbContext();
var product = ctx.Products.Include(p => p.Parts).SingleOrDefault(p => p.Id = 42).
product.Parts.Add(new Part(){Name = "my part"}); 
await ctx.SaveChangesAsync();

In memstate, the command operates directly on the data, you could think of it more like a stored procedure where the properties/fields are the arguments to the stored procedure. Yes, there is a bit of boilerplate but there is no magic or complexity, just a POCO.

public class AddPartCommand : Command<MyModel>
{
   public readonly int ProductId;
   public readonly string Partname;

   public AddPartCommand(int productId, string partName)
   {
      ProductId = productId;
      Partname = partName;
   }
   public override void Execute(MyModel state)
   {
      state.Products[ProductId].Parts.Add(new Part(Partname));
   }
}

So instead of exposing the data model to the application, you encapsulate it and define the operations allowed as commands and queries. I would recommend making the investment to learn this way of thinking instead of going with familiarity.

The memstate tutorial is a good starting point:

https://github.com/DevrexLabs/memstate-tutorial

[TheColonel2688]

Point made, thank you.