Oren Eini

CEO of RavenDB

a NoSQL Open Source Document Database

Get in touch with me:

oren@ravendb.net +972 52-548-6969

Posts: 7,640
|
Comments: 51,273
Privacy Policy · Terms
filter by tags archive
time to read 1 min | 195 words

In an interview with Stallman, the following question came up:

 

If I take a patch under GPL 3 and merge it with a project under "GPL 2 or later," should I write that the new license for the whole project is GPL 3?

The merged program as a whole can only be used under GPL 3. However, the files you did not change could still carry the license of "GPL 2 or later." You could change them or not, as you wish.

 

This means that beyond managing the complexity of a project, with enough versioning problems between the components that I’m creating and the components that I’m using. Now I need to worry about the version of the GPL that the patches are under?

Frustrating 99%

time to read 2 min | 297 words

It’s Thursday’s evening and I’m hard at work at 8 PM, culminating the day. I’d done a lot of code generation and mapping, so I now press the button and wait for it to finish generating the last version. I’m tried but excited since it’s took so long to get to this point, but the code compiles, which is always a good sign J

 

Now all I need is to write a really simple test to verify that it’s working on general, and I’m done for the day. I’m planning on just testing that something really simple works, and leave everything for Sunday. I run it, and the test fails. No worry, I think, I probably forgot something trivial, and so I start investigating it. I quickly find the problem, but I’ve no idea what is causing it.

The issue was that I VS2K5 didn’t add the file extensions to embedded resources. I’d done this sort of thing before, and I know that it should work. I’m banging my head against the keyboard, hoping to get some random key sequence that would fix it.

I decide that I can either stay at this until I figure exactly what is going wrong, or I can just leave it and let my unconsciousness work on it.

 

I decided to drop if for now, and I just solved it! J

It’s a simple matter, seems that MsBuild doesn’t save the file extension for embedded resources when the resource is marked as depended upon some other file. I edit it quickly, and I’m done. It require some few other minor tweaking, but it seems to be working.

SmartDraw

time to read 1 min | 191 words

I just downloaded SmartDraw, it’s recommended by Scott Bellware as a non intrusive UML tool. So I’m checking them out. It’s a tiny download, but then it appears to download the rest using the installer.

It’s an interesting application and I’ve not even got to the File>New… point.

 

1.       I’ve installed as a non-admin, they recognized it, showed a message saying what will not work, and how to fix it. Nice.

2.       I got a flash demo of how to use their product which I’m using now, considering that it’s probably a non trivial application, it’s looking good.

 

I’ve been using if for a couple of minutes, but I really like the interface, looks like it can be used very easily to draw UML, which I was never able to do using any other tool.

time to read 2 min | 244 words

One of the things that bugged me about the SuperFetch demo in the PDC was the declaration that SuperFetch will try to utilize any USB memory on the system to augment the file cache.

On the face of it, it didn’t make sense; the access times for USB 2.0 and modern HD are about the same, with the balance tipping toward HD as the faster.

This post clears things up (look at the comments), apparently this is true for sequential reading, but not for random access, while flash memory excel in random access.

Even with the cost of encrypting it, there should be a good saving in performance that way. I’ll assume that the file cache will look like this:

 

  1. Load to memory the most frequently used programs.
  2. When you run out of the space reserved for the cache on RAM, target the USB drives on the system.
  3. When you run out of USB drives, target the page file.

 

One consideration is what happens when you’ve external HD via USB? I’m pretty sure that they covered this option, though.

 

Cool technology, all around.

time to read 8 min | 1568 words

Note: It's probably pretty early to start talking about patterns for C# 3, but the thought popped to my mind and wouldn't go away.

Mixin: In computer science, a mixin is a group of functions which can be mixed into a class and become methods. They allow certain classes to take on certain functionality, in an object-oriented programming including in languages that do not support multiple inheritance, just as if the class were a cooking dish and a mixin was a specific ingredient.

Ruby on Rails recently got a act_as_taggable mixin, which basically allows you to just slap a single line of code on a class and get tagging support. I'm going to show the C# 3 interface for a similar implementation. I don't care about the implementation, so we'll just assume that this is a given. I want to be able to tag any database object with as few lines of code as possible and just have it work like magic, the ideal is Ruby's single line of code. I'm going to show the ideal, the interface & client code and then talk about how this is possible.

Let's see what we would like to write:

//Createing taggable mixin
public mixin Taggable<T>
{
 public void TagWith(params string tags) { .. }

 public static T TaggedWith(params string tags, FindWith with) { .. }
}
public enum FindWith 
{
 AnyOfTheTags,
 AllTheTags
}
//Adding tagging to a class


public class Photo : Taggable
{
...
}

//client code:
// create photo and adding tags
Photo photo = ... ;
photo = Photo.TaggedWith("flower","sun","yellow""mayhem");
//Loading with tags

Photo photo = Photo.TaggedWith("flower", FindWith.AnyOfTheTags);

This is what we would like to have, but right now and in the future we are not likely to get it. We can get something very close. Here is what we would need to write:

//creating taggable mixin


namespace Tagging
{
 public static class Taggable
 {
  public static void TagWith(this ITaggable<T> tagged, params string tags) { .. }

  public static IList<T> TaggedWith<T>(params string tags, FindWith with) where T : ITaggable<T> { .. }

 public interface Mixin<T> 
  where T : ActiveRecordBase, Mixin<T>   { }
 }
 
 public enum FindWith 
 {
  AnyOfTheTags,
  AllTheTags
 } 
}
//Adding tagging to a class
public class Photo : ActiveRecordBase, Taggable.Mixin<Photo>
{
...
}
//client code

using Tagging;
//create photo and adding tags
Photo photo = ... ;
photo.TagWith("sun","rain","colors");
//load photo with tags
IList<Photo> photoWithFlowers = Taggable.TaggedWith<Photo>("chaos",  FindWith.AnyOfTheTags);

So, what do we have here? We have a static class with extention methods that refer to the Taggable.Mixin<T> interface. The Taggable.Mixin<T> interface require that implementing class will inherit from ActiveRecordBase and implement ITaggable*, this is so the Taggable class will have a way to work with the database, (that is an implementation detail, it can certainly be done in other ways).

Then we have the Taggable class, which has an extention method to add tags to an object, and a static method (not an extention one), which takes a Taggable.Mixin type and return a list of the tagged instances of it. Check out the bolded lines, those is what you've to do in order to get the taggable support for an object. Add a declaration to Taggable.Mixin, and your object is set. Then in the client code just import the Tagging namespace, and you can use it as if it was part of the object.

I think that this is a really nice way to add functionality to objects in a non intrusive way. The client code can actually choose whatever it wants to be exposed to the tagging support or not, and all the class have to do is to declare its intention to accept the mixin.

As I said, it's a pretty pre-mature to start thinking about patterns for C# 3 (C# 2 is not yet released, after all), but I'm willing to bet quite a sum that this will be the way to create mixins is the .Net framework. This is just one of the cool things that you can do with the things that C# 3 will gives you. I expect a lot more goodies along the ways. The new features are useful for so much more beyond Linq.

One thing to considered, it's pretty early to say anything, but I can certainly see libraries such as the Boost providing tremendous value for developers in the C# 3 world.

* Implementing Taggable.Mixin - since Taggable.Mixin is an empty interface, the constraints here are just a way to say that any Taggable.Mixin must inherit from ActiveRecordBase. It's a nice way to declare things, since now we can say: ITaggable<Photo> is ActiveRecordBase, and it's always true.

ReDLinq Mapping

time to read 3 min | 550 words

Dinesh has a post where he talks about the relative advantages and disadvantages of ORM mapping schemes. There seems to be quite a bit of noise about DLinq only supporting attribute mapping in the PDC.

Here is my take on the subject:

Whenever possible, make mapping via attributes possible. The ability to quickly tag a class with attributes and have a workable mapping is very important in most design scenarios, where you want maximum flexibility in changing the mapping. Even though that a compiler can't catch logical mistakes in the mapping, there is a certain class of mistake thati it would catch, so it's good to have it.

Here are Dinesh' take on the  advantages of external mapping:

  1. Same classes can be mapped to multiple data models using different mapping files
  2. Avoids clutter in source code, especially in case of complex mapping
  3. Hides database-specific information from users of object model
  4. Some schema changes can be handled without recompilation (IMO, the class of changes that can be handled is often exaggerated)

I agree that 1 and 3 are good points for extenral mapping, but I feel that they can be hanlded via a secondary mapping which is external to the object while keeping most of the mapping in code. I wrote several applications using NHibernate, which uses XML mapping extensively. It was often a pain to trace the difference between the mapping and the model. The errors can be subtle and hard to track down.

I completely disagree with the advantanges of both 2 and 4. First, clutter in code? Those classes are the gateway to the database, the last thing I want to see is people starting to think of them like normal objects: customers.HugeOrdersCollection.Count - (Load all the orders to memory and return their number, prohibitely expensive operation). The idea in ORM is to make it easier to work with the database, not to divorce all knowledge of its existance. I know that this isn't what Dinesh suggested, but that is the thought behind removing "clutter" from the code.

About changing the schema without recompiling. Care to give me a real scenario where you would be changing a live database where you don't have to recompile? I can't think of any non-really-trivial changes that you can make that wouldn't force you to change code.

time to read 8 min | 1420 words

I want C# 3 to have support for static interfaces! What is a static interface?

A static interface is like a normal interface which a class can implement, but it may contain static methods and constructors. The syntax is simple, just add the static keyword on the methods that you want to be static, add constructors as usual and you're set (I've bolded the new parts):

public interface IDocument
{
 void Save();
 void SaveAs(string name);

 IDocument(IDataStore dataStore);
 static IDocument Create();
 static IDocument Open(string name);
}

public class DocumentImpl : IDocument
{
 DocumentImpl(IDataStore dataStore) { ... }
 void Save() { ... }
 void SaveAs( string name ) { ... }
 static IDocument Create() { ... }
 static IDocument Open(string name) { ... }
}

A class that implements IDocumentCreator must provide static implementation for the Create() and Open() methods. In this case the problem is relatively simple, but in many cases such a thing can be a really big problem in trying to design a class hierarchy where static methods and constructors are part of the interface.

I'm sure that most developers can account for at least one case where they really wanted a way to specify either constructors or static methods in an interface, because that would simplify their life so much. The current solutions are factories [or factories' factories (and so on... )] which suffer from other set of problems or using reflection. Both of solutions are half measures, since it's a way to try to bypass the language limitation and gets the above code to work.

How would I use the above code? Idealy, like this:

public DispalyNewDocument(static IDocument docType)
{
 IDocument doc = docType.Create();
 IDocument doc2 = new docType(dataStore);
 //Dispaly docs.

}

DisplayNewDocument(DocumentImpl);

How would the compiler implement such a thing? Well, for a start, it would seperate the IDocument interface into two parts a static one and a regular one, the static one would result in an automatically generated class, which would implement the methods mark as static as instance methods with simple delegation to the static ones. Everywhere where I need the static portion of the interface, I just use "static InterfaceName" and pass the name of a class. The compiler would then pass an instance of the generated class. The compiler should also be smart enough to turn calls to new InterfaceInstance( args ) to method call to the interface (called Constructor, naturally) which would then return the instance of the class, simply by calling new on it.

The code declaration that I've above should generate the following:

public interface IDocument
{
 void Save();
 void SaveAs(string name);
}
public interface IDocument_StaticPortion
{
 IDocument Constructor(IDataStore dataStore);
 IDocument Create();
 IDocument Open(string name);
}
public class DocumentImpl : IDocument
{
 DocumentImpl(IDataStore dataStore) { ... }
 void Save() { ... }
 void SaveAs( string name ) { ... }
 static IDocument Create() { ... }
 static IDocument Open(string name) { ... }
}
public class DocumentImpl_StaticInterfaceImpl : IDocument_StaticPortion
{
 public IDocument Construcotr(IDataStore dataStore)
 {
   return new DocumentImpl(dataStore);
 }
 public IDocument Create()
 {
   return DocumentImpl.Create();
 }

 public IDocument Open(string name)
 {
   return DocumentImpl.Open(name);
 }
}

And the code that is using it should generated:

public DispalyNewDocument(IDocument_StaticPortion  docType)
{
 IDocument doc = docType.Create();
 IDocument doc2 = docType.Constructor(dataStore);
 //Dispaly docs.
}

DisplayNewDocument(new DocumentImpl_StaticInterfaceImpl());

Using fairly simple transformation and no changes to the CLR itself, we get an incredible boost to productivity via static interfaces. We can now specify all the details about our class, including the static ones. This has a lot of implication on design and totally eradicate a large class of creational patterns, since you can just express them fully in the language.

What do you think?

FUTURE POSTS

No future posts left, oh my!

RECENT SERIES

  1. API Design (10):
    29 Jan 2026 - Don't try to guess
  2. Recording (20):
    05 Dec 2025 - Build AI that understands your business
  3. Webinar (8):
    16 Sep 2025 - Building AI Agents in RavenDB
  4. RavenDB 7.1 (7):
    11 Jul 2025 - The Gen AI release
  5. Production postmorterm (2):
    11 Jun 2025 - The rookie server's untimely promotion
View all series

Syndication

Main feed ... ...
Comments feed   ... ...