search

lapwinglabs / yurt

Yurt: an Ideal Database Client (WIP)
http://lapwinglabs.com/blog/principles-of-an-ideal-database-client
5 stars 0 forks source link

Some Thoughts #1

Open jrf0110 opened 9 years ago

jrf0110 commented 9 years ago

Relational

I feel like the relational aspects of databases need to be represented as well. Even in the case of Mongo, the idea exists in references.

Maybe something like:

client
  .db( pg )
  .get( key )
  .many({ ... })
  .many({ ... })
  .one({ ... })

That might get into ORM territory, though. I think that the majority of the time, your data has relationships, so it would make sense for the client to be able to digest those ideas.

Atomicity

The idea of atomicity across clients is super neato and I think would be totally killer to have. As long as there's a built-in ACID transactor, then it should be fairly trivial to orchestrate. However, databases without transaction/rollback support really can't be relied upon to rollback when an error occurs. Even if yurt only supported a subset of databases, that would be fine. As long it covered a large enough db use-case gamut (application, logging dump, caching, etc.). It could even throw an error or warn about non-guaranteed consistency.

matthewmueller commented 9 years ago

@jrf0110 thanks for your thoughts!

Relational

This one is a tricky one, I haven't seen it done well (especially around limiting the collection size), but your application certainly has to do wayy more grunt work to tie these references together.

I wonder if you could make higher-level chains that would accomplish the same thing just using get's and put's, maybe using .one(...) and .many(...) as sugar on top.

Atomicity

Yep, so in the event of a failed rollback your application would be in an invalid state. The simple way would just be to limit the plugins based on if the databases do rollbacks internally, I think that's definitely the database's job, but yah, maybe we should expose something higher-level, or retry with a backoff algorithm.