Windows Vista Beta 1

One word: GREAT! I like Windows Vista Beta 1. It's awesome to see the cool effects and play a little bit with the windows. My new toy, mine, mine, mine!! ;-)

The beta is sometimes a little bit slow: it seems like the Explorer is thinking what he has to do next. I don't care about that behaviour, it's a beta. Somebody said that the RTM of Vista will be delayed until holiday season 2006. No problem: take your time and create a great OS. I rather like a finished OS then something that needs a Service Pack after two months.

*THUMBS UP* for all the Vista guys! Keep up your good work!

Summertime thundertime

What a lightening! It's happening each summer two or three times that we have such thunder and lightenings here.

The cat was outside and is now completely wet. I've never seen it so wet and so afraid. We had to rescue it (after it went home) from under the bet to dry it.

Windows Vista formerly Longhorn

Against the opinion of a lot other people I like the new name of "Longhorn": Windows Vista. "Vista" has to do with vision and seeing new things - looking forward not backwards.

Great choice!

[Opf3] Firebird storage ready, Rights on persistent objects

The Firebird storage for Opf3 is ready. We had to add a new interface to support the storage. Firebird does not support boolean (nor bit) as native type. Therefore we had to create an interface that allows a storage to convert values to any other type. This has to be done during load and during save. The interface is only implemented by the Firebird storage (right now) and has no inpact on other storages (which was the main goal of the interface).

We created also the possiblity to set rights on persistent objects. You may have persistent objects that should only be loaded and not inserted, deleted or updated. This can be accomplished by setting the right to "Load" and deny all other rights. It's very simple to use those rights:

// Rights are set to "Load" - other rights are denied.
[Persistent("FOO", Rights = PersistentRights.Load)]
public class Foo
{
    // Properties and other code...
}

// Allows to load and insert.
[Persistent("BAR", Rights = PersistentRights.Load | PersistentRights.Insert)]
public class Bar
{
    // Properties and other code...
}

We are waiting to publish the next version because we want to write other test cases and add features. We are currently also testing the framework in some applications (I'm testing it at Sarix and Marco in his applications).

I guess the next update of the framework will be released with the RC1 of the .NET framework (which is targeted to August).

[Opf3] Question: Create one-to-many relations

Christian,

We are evaluating your product here at our company and have a question on WeakPersistent relationships. I have successfuly created a many-to-many WeakPersistent relationship such that removing a mapped object from the ObjectSet of the other does not delete it from the database. However, I am stuck on how to do the same for a one-to-many relationship. Such a relationship has no mapping table in the storage so I cannot create a matching class in the code. What am I missing here?

Thanx
Jay

Answer:
Hi Jay, you don't need any mapping class in a 1:n relationship. It is rather simple to create that one:

[Peristent("FOO")]
public class Foo
{
    private int _id;
    private string _name;

    // Create an ObjectSetHolder of Bar to connect with
    // Bar objects. The relation connects the property "ID"
    // of this class with the "FooID" property of the
    // related objects.
    [Relation("ID = FooID")]
    private ObjectSetHolder<Bar> _bars = new ObjectSetHolder<Bar>();

    public ObjectSet Bars
    {
       get { return _bars.InnerObject; }
    }

    [Field("ID", AllowDBNull = false, Identifier = true, AutoNumber = true)]
    public int ID
    {
        get { return _id; }
        private set { _id = value; }
    }

    [Field("NAME", AllowDBNull = false)]
    public string Name
    {
        get { return _name; }
        set { _name = value; }
    }
}

public class Bar
{
    private int _id;
    private string _text;
    private int _fooID;

    [Field("ID", AllowDBNull = false, Identifier = true, AutoNumber = true)]
    public int ID
    {
        get { return _id; }
        private set { _id = value; }
    }

    [Field("FOO_ID", AllowDBNull = false)]
    public string FooID
    {
        get { return _fooID; }
        set { _fooID = value; }
    }

    [Field("TEXT", AllowDBNull = false)]
    public string Text
    {
        get { return _text; }
        set { _text = value; }
    }
}

As you see you have only to create (in the class that should then contain the list of related objects) an ObjectSetHolder and decorate that class with a RelationAttribute. The first argument of the RelationAttribute's constructor is the property of the single object in the 1:n relation. The second argument is the property of the n objects (the property that is mapped to the foreign key in the database) in the 1:n relation.

You could have a look at the "Relations" sample that is part of the "tutorial and samples" from the Opf3 homepage. That sample contains a one-to-many relation.

If you delete a related object in a one-to-many or one-to-one relation that related object is deleted when you save the "parent" object. Example:

// Load a foo object from the storage.
Foo foo = context.GetObject("ID = 1");
// Delete the first object.
foo.Bars.RemoveAt(0);

// Save the instance of Foo.
// The removed instance of Bar is deleted form the storage.
// In a one-to-many and one-to-one relation related objects
// are deleted from the storage if they are removed.
context.PersistChanges(foo);

In a many-to-many relation the related object isn't deleted because because it may be still connected with another item in the database.

I hope I could help you with this post. If you (or anybody else) has any further question don't hesitate to post them here as comments

[Opf3] ORM - a good idea?

On Codeproject is was asked the following question:

What is your response to veteran developers who assert that object-relational mapping is the "vietnam of computer science", meaning, the amount of input effort far outweighs any benefits it may bring -- what is your thought on that?

My answer was the following:

I can't agree on the blog entry about ORMs being the "Vietnam of computer science". There has been a lot progress in that area.

It's true that Microsoft has dropped the ORM Framework (ObjectSpaces) that was intended to ship with Whidbey. But that was because of other reasons. Microsoft is already using an ORM Framework in some of their applications (for example Exchange Server). They are creating WinFS for Longhorn (which hasn't been dropped, but only delayed) and then they were creating ObjectSpaces. That's three different ORMs - I guess (and I heard from people at MS) that this was to much for them. They didn't simply want three different frameworks for the same topic. They are now putting all their efforts in WinFS to create one framework for all.

Back to the progress: There has been a lot progress in the ORM field. Compare for example OPF.NET with Opf3? In Opf3 for a lot scenarios you don't even need to write SQL. Each storage class (each class that encapsulates a database) creates the SQL by itself, optimized for that storage.

Opf3 for example allows you to create very slim persistent objects: they are then serialized and remoted to any client. The overhead is quite little because the object consists only of those properties you want to load from the database. You may have 10 fields in the database and only load 2 of them and update only the two of them. Simply create an object that maps only to the two fields and you are good.
We are using OPF.NET with .NET Remoting in an application server. That server is doing all the loading from database, sending the objects to the client (up to 300 clients) and saving the objects back to the database. The clients are only modifying data in the properties of the objects; they don't even know that those objects came from a database. We didn't never have problems with that server. It's working very fine (also under heavy load).

My personal impression is that by using an ORM I'm a lot faster in creating database access and accessing the data in that database (like 50-90%). The ORM allows me also to implement design patterns a lot easier, because it gives me objects and not relations. Another benefit of ORMs is compiler time errors. If you use generic DataSets you don't get any error (during compile time) when you try to access a field that doesn't exist. With an ORM you get an error because you try to access a property of an object that doesn't exist (=> typos).

It's not so important that you may switch from one database to another by simply changing the storage class, it is more important to move the errors from run time to compile time. Another big pro is having a well designed class structure that allows you to add new features in a short time. Not being limited in the relational paradigma is also a very nice benefit. Why shouldn't you use all features of the object oriented model (for example inheritance) in your database objects when you use those features also in all other parts of the application?

Started work at Sarix

Yesterday I started to work for Sarix (my summer job). We are using Opf3 in a new project. I think that I'm going to improve the framework a lot during this summer. We are also going to write (possibility of 99%) a storage for Firebird. That storage is then used within the project. It's not totally clear until now, but I think we will end up with Firebird. Firebird has very little need of memory and is quite easy to install (you have only to copy one DLL).

I guess the storage will be free for download from the Opf3 homepage when done.

Cool Steve Ballmer video on C9

Robert Scoble has posted a cool Steve Ballmer interview on Channel9. Check it out!

Finished university for this term

I finished university for this term and did 11 exams this term. I'm very happy because this is a big step to my final grade. :)


Hmmm: What's going on in London?! :( I guess it is terrorists, again.


Strange life: one moment you are happy, the next you are sad.

[Opf3] My own storage

The framework exposes a few interfaces (for example IStorage and ITransactionStorage) that allow you to write your own storage for you a database that is not supported by Opf3. But storages are not only limited to databases. They could also be INI, XML, CVS and any other file format/type.

If you want a template to create your own storage you should download the storage for VistaDB, PervasiveSql or PostgresSql. They are available with the full source code from the Opf3 homepage.

If you are willing to contribute the storage classes to the community you are welcome. Please send them to us, using the e-mail address that is found on the Opf3 homepage.