Links:

• Jevolution writeup
• applet page
• Jevolution source on github

This was the mistake:

alias local='git checkout local'

The next time I opened a terminal, I received this wonderful message:

bash: /etc/bash_completion.d/gdb: line 23: syntax error near unexpected token `('
bash: /etc/bash_completion.d/gdb: line 23: `            local path_array=( $(echo "$PATH" | sed 's/::\+/:/g;s/^:\|:$//g') )'
bash: /etc/bash_completion.d/vncviewer: line 92: syntax error near unexpected token `('
bash: /etc/bash_completion.d/vncviewer: line 92: `        local dash options=( \'

I had done several other things before opening the terminal, so I didn’t immediately recognize the alias as the culprit. The message just confused me more. The terminal still seemed to work properly.

Took some time, but I narrowed it down to that alias. Turns out that local is a bash builtin command and using it as an alias command is a syntax error. The message has to do with where the .bash_alias file is included and evaluated.

Here’s the main point of the post:

Always remember to test aliases before adding them to the .bash_aliases file. Check the man pages, google it, actually type it. I have been surprised several times by how many two- and three-letter commands that already exist while thinking of short aliases for common commands.

And read the bash reference manual. There will be a test on Tuesday.

%w{there will be four\ elements}

evaluates to:

['there', 'will', 'be', 'four elements']

Just a little neat tidbit I haven’t seen in any examples.

These are the choices for accessibility in C#. They are roughly in order of decreasing accessibility. However, the internal keyword messes things up a bit.

public
Any class in any assembly can access something with this modifier.

protected internal
Any class in the same assembly can access this. In other assemblies, only child classes can access this.

internal
Only classes in the same assembly can access this.

protected
Only child classes can access this, regardless of assembly.

private
Can only be accessed within the class where it is defined.

Some posts/articles that helped:

• http://www.gotw.ca/publications/mill18.htm
• http://haacked.com/archive/2007/10/29/what-does-protected-internal-mean.aspx

After working with Evan on a db4o-based project for a while now, I too have some constructive criticism for db4o. Before I get to the criticism, though, I’d like to add that I really enjoy using db4o.

In contrast to db4o, we had initially tried ORM’s like NHibernate and SubSonic, but we always found ourselves back at the same spot… we weren’t actually getting anything done! We were either fighting with installing SQL Server (which, on one attempt blue-screened my computer and necessitated a full reinstall of Windows) or fighting with learning and/or configuring the ORM’s. Among other time sinks, we had to figure out a way to synchronize our SQL schema changes between me, Evan, our development server, and SVN. The story goes on and is exceedingly painful to add up all the hours of wasted time. It all boils down to one question: Why should you have to learn something completely unrelated to the domain of your project just to get things done!

The lustre of a purely object-oriented database is too strong to deny. Think about it: no more object/relational impedance mismatch! No more schema synchronization! No more battles over who’s ORM is the best! It is in these pillars of data-access where db4o shines. Db4o tries its hardest to get out of your way and let you get on with your work!

My following criticism about db4o should be taken constructively: in all honesty, I want to use db4o and forever do away with the other DB/ORM “solutions” out there. IMHO, db4o is all about getting things done, while the other solutions are all about picking the color of the bike shed.

1. db4o transactions

The transactional nature of db4o is not up to par with the offerings of NHibernate, ADO.NET, etc. I know this is like comparing apples to oranges, but I think it still holds that db4o’s transactions need a first-class presence.

2. “Real” lazy loading support

Without lazy loading, db4o forces you to choose a load-depth each time you run a query. If you don’t chose a load-depth then db4o uses a default value (5, I think). Either way, you must be aware of the consequences of choosing load-depth values.

If you choose a load-depth value that is too large, you will load more data than you’ll actually use which, in turn, negatively affects query performace. But, if you choose a load-depth value that is too small, you will not load enough data and db4o will leave any references to data beyond your load-depth value as null. Hopefully you are aware of this gotcha and have implemented null-checks throughout your data-access codebase.

Dealing with the load-depth problem forces the developer to be aware of intricate low-level details of their domain persistence, which no developer should ever be burdened with. Heck, isn’t this is why we’ve chosen to program in higher-level languages!

One of the most important reasons, if not the most important reason to do-away with load-depth, is that once you choose a value, you are tightly coupling your codebase to a magic number that you’ll need to remember to update whenever you change the structure of your domain.

If you choose not to tightly couple your code with load-depth values, you’ll use the default load depth. But with the risk of not loading enough data still present, you’ll still need to include null-checks. Though it is a simple stop-gap solution, using the default load-depth is definately not optimal. We need the ability to load the exactly amount of data that we’ll use: enter lazy loading.

Yes, I’ll admit that db4o currently offers a lazy loading solution, albeit a _very_ bad one at that! They’ve “implemented” lazy loading via a post-build process (yuck!). In my opinion, this doesn’t even constitute a viable option. If NHibernate can do lazy loading (via Castle’s DynamicProxy, or linfu) without requiring an added post-build process, so should db4o.

3. Built-in change tracking

This almost goes hand in hand with #2. Though Db4o makes saving a new object graph to the database very easy, updating data requires the developer be aware of details they shouldn’t be bothered with (hey, just like with load-depth!).

First, you have to make sure the object you are updating is loaded from db4o. You can’t just create a new instance of the object with the updated data and save it to the database: this will not have the effect of updating the original object, instead it will save a new object to the database! Granted, this requirement is understandable; but then again, it isn’t this requirement that I’ve got a beef with.

Now that you’ve made sure your object has been loaded from db4o before you begin updating it, you need to make sure that the object’s graph (i.e. references from your object to other objects) has been loaded to the correct load-depth; just because one of your object’s references is null doesn’t mean there isn’t an object referenced – it’s just that db4o might not have loaded it. If the object you’ve loaded from db4o has a null reference to an object which actually exists in the database but wasn’t loaded by db4o (due to shallow load-depth) and you replace that null reference with a new object, when you save your updated object (the one that was initially loaded from db4o) db4o will happily save the newly referenced object without complaint while silently leaving the previous instance untouched in the database. This creates what I like to call a “dangling object” because nothing points to it anymore! This problem is only worsened by the fact that you can’t (easily) load the database into a manager to look for these “dangling objects”.

With proper change tracking implemented, developers shouldn’t be bothered with keeping track of load-depths when updating an objects.

Final thoughts

Although I think db4o has some major shortcomings, I think it is a promising project. With these items addressed, I think db4o could be a major contender in the DB/ORM space.

The ultimate use for this will be in games. I want to be able come up with naming conventions so that I can generate internally consistent names for places, characters, and items.

I hacked together a hard-coded version and put it up on Bitbucket. I called it RName. The project page is here.

It’s very bad code right now. I just got something up there so I would have a starting point.

My next steps are:

1. spec out the grammar for the grammar files
2. get a parser for the grammar files
3. write the actual generation code
4. make a ui or console frontend

Time for flashbacks to compilers.

The one currently offered by Versant (the company in charge of db4o) is not usable. It exists solely as a plug-in for Visual Studio. I could overcome this, but the plug-in messes up all my Visual Studio settings. Also, while it’s installed, I can’t fix any of those settings.

So I’m going to try making my own. I want it to (in approximate order of importance):

• view metadata stored in a db4o file
• view data stored in a db4o file
• run readonly queries on a db4o file
• edit data in a db4o file
  • add new instances to the db
  • edit current instances in the db
  • remove instances from the db
  • perform batch updates / deletes on instances mathching a filter
• manage indeces
• attach to an opened db4o file
• handle migrating objects to newer versions
• intercept traffic between an application and db4o for reporting

I am also going to do this as a way to learn WPF. I’ve messed with it a big and found it interesting. Much easier than any other windows programming frameworks I’ve looked at.

I shall name the project Grot. There is nothing special about the name. Right now the code is just a spike of me messing with WPF and db4o’s metadata. You can find the code here.

You’ll need mercurial to work with it. If you haven’t tried mercurial for source control, do so now. I have really enjoyed using it and the Windows client, TortoiseHG has been a breeze to use. I’ve been using Bitbucket to host my central mercurial repositories. The site is slick and hasn’t gotten in my way.

1. There isn’t a usable manager for it. The plug-in for Visual Studio isn’t usable.
2. There is no built in support for associating ids with objects. This is important for web work.
3. There is no easy way to enforce uniqueness constraints at the database level.

The first one is the biggest issue. Using db4o without a way to check and edit the contents of a database makes development much harder.

Brad and I have put together solutions to the second two, but neither of us are satisfied with them yet.

I have started working on a db4o manager. I got a couple things working and need to create a plan for how I want to move the project forward now that I’ve figured out how to start.

My current programming partner has expressed interest in sharing his programming experiences as well.

The apparent lack of quality media coverage on politics for the last couple years has finally made me decide to do my own research.  I may post findings here.  I may do that on another site if it interferes with technical posts and discussion.

For the near future, I’ll be posting about issues from the last year or so.

More later…