Stralep asked "But why are relational types limited only to be composed of primitive types?". Well, most SQL-based databases are like that, and you link separate relations together using foreign keys. It would be an interesting feature if they made it hold hierarchies of objects, but then, that reduces the ability to perform relational algebra operations because you'd be hiding parts of your relations in those nested structures. That becomes an SQL vs NoSQL debate. Object Store vs. relational data.
I notice that they have a very simple distributed mechanism. You can have many instances of "executors" (the interpreter / computation handler) and of "volume" (data storage and access), but just one transaction manager. Seems pretty simple. What I want to know is how this compares to the speed and scalability of MySQL. Do I want to start replacing my MySQL servers with bandicoot?
It also occurred to me that you essentially have a stored-procedures-only system here. You can call any function via http but you can't execute arbitrary queries. Aside from that, I don't see any built-in security other than placing this behind a firewall if you want to limit it to only back-end server use in your PHP/Ruby/Java/Arc/etc. applications. You will have to edit the bandicoot code file in conjunction with your web app code to incorporate all the queries you need, but that separation of concerns could be considered a good thing.
I'm not clear on how bandicoot handles durable persistence (ie, integration with SQL/NoSQL datastores), or if it is intended to replace them.
All in all, very interesting.
The main goals of the Bandicoot system are:
- efficient implementation of the relational algebra
- clean language for programmers (rather than "English speakers")
- easy to understand transactions
- open interface
- small code base