Tag along

I gave Mats a call the other day for a quick chat. I had just about hung up the phone when he tagged me… Thats a friend for ya. OK, I’ll play by the rules, and tell you five things (most of) you didn’t know.

Mountains

* I love mountains. I love watching mountains, and the best view you get from the summit. I love walking in the mountains (I went with a friend for a long weekend trip to the Swedish mountains last fall). I love climbing mountains. I’ve made three trips to South America to climb mountains, summited Aconcagua (6959m). I love mountains so much my kids are named after two of the Swedish mountains. Unna-Jiertasj and Keb

Food and cooking

When I was a student, I’d usually settle for Pasta Rosso (spaghetti with ketchup), but I was also a member of "Nisses Stuga" (we met once a month and prepared a 3-4 course gourmet dinner together). I can still follow a recepie, and my favorite dish to prepare is "Kreolskans Söndagsgryta". However, my real favorite is to make a lot of food at the same time. I often make lasagna from 3 kg minced meat and stuff the freezer full. I also like to take care of things I can get for free such as berries, nettles, rosebuds. I have a couple of really nice liquer made from "aronia berries" and "blackthorn". We currently live in an apartment, but one of the criteria when I look at a house is that it has to have a food cellar where I can store all the stuff I want to make

Geocaching

I got a GPS navigator for xmas ‘05, and I’m now a geocacher. I’m currently in possession of two travelbugs (Quito Kid and Grumpy). If you are in Germany and know about geocaching, Grumpy would very much like to stop by for a visit. I have yet to find my first international cache.

Bike

I ride my bike to work every day . I do this both summer and winter (winter time I use studded bike tires). This is good since I don’t practice any any other form of exercise. This winter has been good for biking. It is the middle of January and it is still 8C. I occasionally take the car to the office, but after a blizzard last fall when it took me 8h 45m to get home (normally takes 15-30 minutes), I really think twice before I skip the bike.

Computer History

I’m just about to turn 35, and since I got my first computer when I was 11, there is already quite a lot of history. I started programming Basic on the C64. Me and a classmate wrote a text adventure called "The hidden forest". The source is lost, but it was similar (and modeled after) "The fourth sarcophagus" We went on to the PC and Turbo Pascal 3. Me and Jesper started writing a navigation application for helicopters in the north sea, but it never went into production (probably a good thing, we were no more than 14/16 at the time). We wrote our first frameworks when we were working on a data entry application for a Swedish wine maker. When I went to University, I spent my nights and weekends writing the best Ansi editor there ever was. I also ran a BBS back then, MayDay BBS. As a project in university, we wrote an incremental C++ pre processor (cppi). God, those 4 pages of specification for cpp sure are easy to screw up :-). I did my final thesis for a company called SoftLab where we worked with improving their parser generators. By a series of coincidences I ended up at BoldSoft where I’ve been working ever since (well, there has been an acquisition and a divestiture, so formally the company is now CodeGear

Tag along

Now, I just have to figure out who to tag from here… I’ll just use Mats method and tag someone who called me recently… [Jonas looks on his cellphone who called him recently...] Nope, no bloggers there… I’ll check my skype log instead… Holger Flick, Jan Nordén, Jesper Högström, Peter Morris and John Kaster. Guys. You are it now!

Share This | Email this page to a friend

Posted by Jonas Hogstrom archive on January 16th, 2007 under Uncategorized | Comment now »

Scope rules in C# 2.0

The scope rules in C# 2.0 changed ever so slightly. Consider the following code:

	class MyAttribute:Attribute
	{
		public MyAttribute(Type t)
		{
		}
	}

	[MyAttribute(typeof(Bar))]    // Look here...
	class Foo
	{
		class Bar
		{
		}
	}

	class Bar
	{
	}

To make it easier to spot, I have added a comment where you should focus your attention. In C#1.0, the reference to Bar in the constructor parameter of MyAttribute would reference the "outer" class Bar, but in C# 2.0, the same code references the inner class Bar (Foo.Bar). In Eco, this happens with the code for the domain classes if you use association classes (the association is represented with an "inner class", and the association class with an outer class that has the same name). It was easily fixed by adjusting the Eco code generation to emit fully qualified names (typeof(namespace.Bar)), but it took quite some time of debugging to figure out what went wrong…

Share This | Email this page to a friend

Posted by Jonas Hogstrom archive on December 11th, 2006 under Eco | Comment now »

ASP providers for Eco - work in progress

It was a long time ago now that we released EcoIII along with BDS 2006. The Eco team has not been sitting idle since then. As you probably know, the first shift we did after releasing BDS2006 was to move the IDE to compile with .NET2.0. For Eco, most of the work was adjusting the build scripts to use the new assemblies. Bit by bit we have added features to the IDE and to the Eco framework to support the stuff that is in .net2 (along with all features that are independent of CLR-version).

Another long time ago, the Eco team went on an ASP2 preview seminar, and one of the ideas we had when leaving that seminar was that we should provide Eco implementations of the ASP2 provider architecture (MembershipProvider, RoleProvider, ProfileProvider etc). At the time, we had not yet released BDS2006, and our code base was still with net1.1, so there was little we could do at the moment. It did in fact take quite some time before the BDS ASP designer was up and running with support for .net2, so we pretty much forgot about the ASP provider architecture until a meeting with the Eco "Miniteam" the week before last (the miniteam consists of R&D, QA, pubs and a few other internal stakeholders who might have an interest in what we are doing :-). In this particular meeting, Jim Tierney brought up the ASP providers, and I got a flashback. Said and done, later that evening (my wife was out of town, so no one told me to go to bed) I started to implement the MembershipProvider using an "Eco backend". Right now, I have MembershipProvider, RoleProvider and ProfileProvider up and running, and most of PersonalizationProvider.

This makes it possible to use standard ASP.Net2 components like LoginStatus, LoginView, ChangePassword, PasswordRecovery out of the box.

The first implementation just provides an Eco package with a bunch of classes, and implementations of the Provider classes. The application needs to supply its own EcoSpace (that must be configured with the above mentioned package). Then all you have to do is to configure your Web.config to use the Eco implementations of the providers:

 <membership defaultProvider="EcoMembershipProvider">
  <providers>
   <clear />
   <add
   name="EcoMembershipProvider"
   type="Borland.Eco.Web.AspProviders.EcoMembershipProvider"
   EcoSpaceTypeName="EcoAspProviderDemo.EcoAspProviderDemoEcoSpace"
  />
  </providers>
 </membership>

Under the hood, the provider will manipulate objects that will belong to your Eco application, and store them in your "Eco database". This could be in Oracle, Interbase or an Xml-file (yes, in Highlander, you can use PersistenceMapperXml on a PersistenceMapperProvider).

My plan is to provide a "self contained" version of the providers as well to allow people to use the ASP providers with any database without necessarily having to write the rest of the application using Eco. All you would have to supply is a connection string (instead of as above, an EcoSpace). This would probably mean that we will distribute something similar to aspnet_regsql.exe to setup the required schema in an eco-supported database. One of the advantages of this is that we can slip in Eco in non-Eco projects, and hopefully attract the interest of a few new developers

Share This | Email this page to a friend

Posted by Jonas Hogstrom archive on December 11th, 2006 under Eco | 3 Comments »

ECO II and support for custom Ado.Net providers

Hi Now that Delphi2005 Update2 is out, I have updated my (short) tutorial on how to support a custom Ado.Net provider in Eco: http://homepages.codegear.com/ecoteam/johogstrom/CustomPMapper/ The tutorial contains an example of how to support the MimerSql database (both the Bdp provider and the native client). The source can quite easily be copy/paste/modified to support other providers. If you use it to write your own provider support, please let me know. /Jonas

Share This | Email this page to a friend

Posted by Jonas Hogstrom archive on March 14th, 2005 under Eco | 1 Comment »

Reverse engineering the blog database

If you have watched Henriks reverse engineering of the northwind database on BDN, and you want some more meat on the bones, I suggest you read my article on how to deal with the finer details on customized O/R mapping with Eco II. Find it right here.

In the article I’ll walk you through, step by step how to handle the cases when the initial reverse-engineering does not yield the expected/wanted result.

Feel free to comment the article here.

Share This | Email this page to a friend

Posted by Jonas Hogstrom archive on December 3rd, 2004 under Eco | 1 Comment »

Re: Re: Eco: Optimistic Locking

Before reading this, I suggest you start with Malcolm’s blog "Eco: Optimistic Locking", and then Krishnan’s follow up blog on the same topic. Both are well written pieces of information on optimistic locking in Eco, but neither of them comes from the horse’s mouth

Hi by the way, and welcome to this first blog post. Here I’ll try to cover some of my responsibilities in the Eco II model powered framework. I spend most of my time working on the O/R mapper and all that is related to that or the OCL evaluator (or a combination of the two such as converting OCL queries to SQL queries). Anyway, back to the topic.

First I’ll explain a small detail that Malcolm got wrong regarding "TimeStamp locking". Each object in the database has a timestamp that is independent of every other object (it is stored along with the other attributes of the object). Every time the object is updated it will receive a new timestamp, and this timestamp will be the same for every object updated in the same transaction. You could think of the timestamp as a transaction number. When the timestamp is validated, Eco will fetch the timestamp for that object from the database, and compare with the timestamp that was retrieved when the object was loaded into memory in the first place. If the timestamps are not equal, it means that the object has been modified by someone else.

This means that if one client updates an Appointment object, this will not prevent another client from updating a Person object. If that had been the case, it would most certainly have been a bad thing since it would make it completely impossible use timestamp locking if you are writing a multi user application (and if you’re not writing a multi user application, there is little need for optimistic locking in the first place)

The sql-statement that Malcolm mentions: "UPDATE ECO_TIMESTAMP SET BOLD_TIME_STAMP = BOLD_TIME_STAMP + 1" is executed once at the start of the transaction (actually, just before, in a separate transaction) and simply allocates a new transaction number to be assigned to all the objects that are about to be updated. If the optimistic locking fails, the timestamp that was allocated will not be used. This could be regarded as a waste, but hey, it’s just an integer If you use one transaction per second, 24/7, including Christmas Eve, you won’t run out of integers for 60 years.

Now on to Krishnan’s blog. After reading Malcolm’s blog he has a few concerns about the optimistic locking in Eco. The first concern is regarding efficiency. Eco currently validates the optimistic locking by issuing a SELECT statement to retrieve the database values and compare them to the values that were previously loaded. It is true that when you update one object, there will be two statements sent to the database. One to retrieve the old values, and if they are OK, Eco will then execute an UPDATE statement. However, if you update multiple objects, Eco will load the data for validation more efficiently, especially if you are using timestamp locking. Normally, the timestamp field is located in the same table for all objects, so the timestamp data for a whole batch of objects can be loaded were with a single SELECT. So as for performance and scalability, the price you pay for validation will always be smaller (and with timestamp locking, magnitudes smaller) than the price you will have to pay anyway for the actual update.

The suggested solution to get rid of the SELECT statement is to include the validation in a WHERE clause to the UPDATE statement. Yes, Eco has all the information available to append this WHERE clause, and I agree it would be wise to do this where this is appropriate. IDbCommand.ExecuteNonQuery (The ADO.Net function that Eco uses to send the update statements) will return the number of rows affected by an UPDATE statement, so it is possible to detect if the conditions were not met, and then roll back the transaction and throw an (optimistic locking failure) exception. [Note. Some databases supports batch updates, which would complicate the case a little, especially if this batch behaviour was hidden behind the scenes by Bdp (Borland Data Provider) for example. ]

However, the optimistic locking scheme in Eco is a little more generic that it might appear when you read Malcolm’s blog.

First of all, if an object is located in multiple tables (perhaps because of inheritance in the model), it is not certain that all tables will be modified when you save the object, but if the mode is "AllMembers", you would still want to validate the values in tables that you are not going to UPDATE. This could possibly be achieved with a little more complex WHERE clause where you nest an inner SELECT to compare data from the tables you are not going to update.

There are however even more complex scenarios… When the EcoSpace sends a batch of objects to be updated, it will send a block of data that should be validated. The data in the datablock will contain the "old" values of the objects that are about to be updated, but is not limited to this. It could contain values from any object that happens to be loaded in the EcoSpace and that for some reason or other needs to be validated (that it has not changed).

Imagine for example a model with a Customer class that has a credit limit, and a association to an Order class (0..*). When the credit limit is changed, you would want to make sure that no other client has added a new Order to the Customer (if the credit limit is lowered, the other client might have placed an Order that takes the Customer above the new credit limit). This can be achieved in Eco by specifying a "region" that covers the credit limit attribute, and the relationship to orders (the region concept is a big topic in itself, and will not be covered here). If the credit limit has been modified, the datablock that contains values for the optimistic locking will now contain not only the old values for the customer object, but also the value of the relation from Customer to Order. The value of the relationship is not stored in the Customer table. It is not even stored in a single row in the Order table. The region mechanisms will actually allow you to specify the dependency between objects that are further apart than one association; perhaps you would want to validate that no one has added an OrderItem to any of the Orders that the Customer already has, or changed the quantity of an OrderItem.

Also, as some reader commented to Krishnan’s blog, blob fields can not be used in the where-clause, but they can be fetched with a select and compared in memory (expensive, but possible if you for some reason don’t want to use timestamp locking).

The second main concern in Krishnan’s blog was regarding isolation levels. Indeed, READ COMMITTED is not enough to guarantee the optimistic locking when some data is validated in memory with a separate SELECT statement, actually, not even REPEATABLE READ is enough to validate an association like the one above between Customer and Order. In order to make sure that no one adds a new Order to a Customer after validating that the existing set of Orders has not changed, the isolation level must be SERIALIZABLE, but this would unfortunately prevent anyone from adding a new order to any other customer. Eco does not enforce any particular use of isolation levels, the developer will have to decide this and weigh the pros and the cons with each isolation level.

So to summarize: Eco could certainly benefit from using WHERE clauses in the UPDATE statements to validate the optimistic locking, but this will not handle all aspects of optimistic locking in Eco.

Share This | Email this page to a friend

Posted by Jonas Hogstrom archive on October 22nd, 2004 under Eco | Comment now »