Comments about use in production

[3noch]

I'm hoping to use Project-M36 in a (small) production-level application in the next few months. Would you say Project-M36 is ready? My application will be small and have relatively low demand on performance, but I want to use it as a trial run in hopes of using this in bigger projects in the future. Do you have any advice?

[agentm]

I would say a small starter project would be the perfect way to get your feet wet with Project:M36.

I am not aware of any issues that would prevent use of Project:M36 in practice, but I do have some niceties in the pipeline (like #33). Also, currently, there is no daemon mode- that would be useful for real installations.

Project:M36 has a lot of interfaces (websocket server, Haskell server, tutd, persistent driver, in-memory mode). Which one do you plan to use?

On a related note, perhaps it is time to create a mailing list for Project:M36 for discussion purposes.

[3noch]

Awesome! I can't wait. I still have a lot to learn about the project but I'll be writing the application in Haskell so I'd like to quickly get DB features without having the overhead of a different database system. I also think Project-M36 holds a lot of promise to simplify the DB layer. At this point my guess is that I'll use the Haskell server and possibly the websocket server as well.

Yes a mailing list would be swell. Alternatively/additionally you could have a Gitter, Slack, or IRC chat room.

[agentm]

Hi @3noch, it occurred to me that there is at least one problematic issue without a clear resolution yet. It's being tracked as #43.

[3noch]

What about migrations? Does Project: M36 have a story for that yet?

[agentm]

If you are referring to migrations across Project:M36 releases, then, short answer: no, the on-disk format is just Binary structures and we plan something better-suited once some other related features are in place.

If you are referring to schema migrations, then Project:M36 schemas benefit from the same transaction isolation as any relational database context expressions (update, delete, insert). Users are responsible for adjusting their client code for accommodating schema changes, though. One exciting feature coming down the pipeline is "isomorphic schemas" which will allow disparate clients to depend on different variants of the same underlying database so that client migrations can be phased in.

Do you have a more specific use-case in mind? I would be glad to hear more about it.

[3noch]

Thanks. I was referring to schema migrations.

Wow. Isomorphic schemas sounds incredibly awesome. Are schema changes able to be done inside of a transaction (like Postgres allows)?

[agentm]

Project:M36 schema changes are completely isolated transactionally, even more so than postgresql, which holds locks for schema changes. Also, schemas can be branched and merged alongside their data. In this context, there is no difference between DML and DDL.

[3noch]

That's pure awesomeness.

[agentm]

A first pass at isomorphic schemas is now in available in the master branch with documentation.