Fog Creek Software
Discussion Board

Welcome! and rules

Joel on Software

Anyone used Bamboo?

What do you think?

Thomas Eyde
Saturday, October 18, 2003

While it looks interesting, I'm not going to be the first one to abandon the decades of relational database research, development, principles and practices to adopt something that a couple of guys built in their spare time.

I might play around with it to see how it works, but as a replacement for SQL Server, I'm doubtful.

I think the biggest advantage relational databases have over object databases (or XML databases) is the power of SQL based queries.  Until a standardized language for querying becomes available and readily adopted by tool vendors, your risking storing your data in a system that has problems playing well with others.

Guy Incognito
Saturday, October 18, 2003

You may want to look at Not free (though they have a free developer's edition), but it appears to support standard SQL in addition to being object oriented...

Brian Kavanaugh
Tuesday, October 21, 2003

Yes, I've used Bamboo.Prevalence. 

My feelings on it are very mixed.  If you want other's opinion go to slashdot and search for prevayler (bamboo started as a port of prevayler from Java to C#).

First the positive: Bamboo lets you live mostly in object land.  It's quite nice to be able to ignore DB mapping and data access logic.  Plus you don't need a DB for it. 

BUT there are a number of catches.  The first is that you don't get really pure O-O.  You use command objects to encapsulate actions against an "engine" (really a facade of the underlying object-graph).  Bamboo offers some cool things that Prevayler doesn't: you don't need to code these command objects, the TransparentEngine creates implicit ones for every method invocation.  (For every method not marked with the PassThrough or Query attributes.)  BUT these commands (methods) must not contain references to objects already in the object graph!  Wny not?  The basis of Bamboo is 2 ideas: 1. serializable objects and 2. command objects that can be rapidly serialized so that one can have a state restored after a crash.  If you have direct references to your objects in a command then you risk having your entire object graph (or a significant subset of it) serialized for a single command.  That blows away the whole premise of this approach: to whit: command objects can be serialized FAST.

But that's not the real problem with this approach.  Here are the problems:
    No 3rd party (command line, gui, reporting engine, etc.) access to your data.  Yup, you're SOL it's locked in your objects.
    Single instance ONLY.  If you run a busy web server and multple app instances are started to service requests each one will have it's own Object graph.  Bamboo provides nothing at all to bridge this.  The built-in .Net serialization and remoting go much of the way to provide for distribution, which you now need but you have to write the rest.
    Not ACID compliant at all.  Period. 
So, where would I use Bamboo:
    * simple stand-alone apps.
    * as a quick-save mechanism for single-thread processing of some sort .. with other data eventually rolled into a proper DB
    * to get a simple proof-of-concept app up.

It's more than a toy, but it has limited usage.  And, despite the Prevayler web site, the idea of prevalence is much older and reasonably well studied.  It is not a good general data storage technique.

There's another big "gotcha" which is data migration/versioning.  Object serialization is specific to the the version of the class for which an instance was serialized.  Add/remove/rename an ivar and deseralization breaks!  Whoops.  In the original Java version that's a big Whoops.  Bamboo has a very cool migration utility.

Anyway, different folks have different tastes.  If you've never used it an are needing something quick for a small app/site, give it a try, you might love it.  If you've never done object-based data maniplation (and, no, ADO.NET does not in any way qualify in that regard: the "objects" in ADO.Net have ZERO to do with the business objects that a proper O-O approach has in mind when the terms like ER modeling, etc. are used) then really do a simple project with Bamboo -- that is very cool.  Then you'll see why folks are still clammoring for the chronic vaporware known as object-spaces and also why Hibernate, JDO, et. al. are such big hits.

For bigger apps my recommendation is:
    * Buy a proper O/R mapping tool  ( <  $1,000)
    * Use ADO.Net and hope the system req's don't change
    * Use Java like everybody else.

Ezra Epstein
Tuesday, October 21, 2003

Erza, thanks for the good review.

Guy Incognito
Sunday, October 26, 2003

"Use Java like everyone else."

Da fug?  Come on, man.  ADO.NET is way faster and in some ways more flexible than JDBC.

As for Bamboo...while I wouldn't suggest it to everyone, we already had a pretty whiz-bang database abstraction layer, and tailoring it for use with Bamboo was just a matter of refactoring the RecordFactory.

We don't use Bamboo full time.  We use it for disconnected clients who want to bring their laptops with them when they're out of the office and synchronize their changes with the home server.  It took nearly as much time to engineer this solution as it did to figure out a multi-homed DTS system, and it was both cheaper and easier to understand.  Plus it'll run everywhere and doesn't rely on MSDE, flat files or Access.

Monday, June 06, 2005

One more quick thing on ACID compliance: you get some of it out of the box (basically Isolation, through the command stack).  Atomicity and Consistancy depends on you programming your objects correctly; if you ignore exceptions or allow the user to create more than one object with the same primary key you can't blame Bamboo for saving it that way!  Durability is the real question here, and it depends what's important to you.  Certainly you can tailor Bamboo to fire an event to write to the transaction log on disk after each command, in which case you'd have your ACID.

The big problem with Bamboo is the paucity of good tools for probing the object store.  Honestly, if I use it on another project I'll start building and hopefully OSS-ing basic reflective query tools -- our primary database abstraction layer being based entirely on reflection, I have something of a Rosetta Stone between SQL and Bamboo.

Monday, June 06, 2005

*  Recent Topics

*  Fog Creek Home