A New Challenge

It has been a while since my last post, having been really busy at work getting some projects completed.  However, as its the start of a new year, I'm thinking I should get back to blogging.

So, I'm going to start work on a new self learning project, like the Java OData and the SQL audit tools I wrote previously. While I'm not going to share what the project is, I will try share what I learn while doing the project.  What's the point of working on a project? Well, I like having a purpose for doing something. I like to have a goal and try to meet that goal. Also, I am working on my project from the beginning, to see thoughts turn into requirements into functionality. But when it comes down to it, I just like a challenge.

Now the basic frameworks/languages/processes will be MVC 4, C#, Razor, agile, HTML5, CSS3, WCF and MS SQL 2012.

I already have some ideas for some future posts, so watch this space.

nHibernate, Lazy Loading and AutoMapper

I know its been a while since I have last posted, and unfortunately this post is going to be short, but I have just gotten something working and thought that I would share it with you all.

Here is the senario: you have nHibernate (in my case fluent nHibernate) and you have some collections (and properties) to be lazy loaded.  You also have your entities mapped to a DTO entity for sending over the wire.  Now, my problem was that the lazy loading was not working, when I monitored the SQL trace I could see every member and every collection being loaded regardless of what I had configured in nHibernate.  This was causing around 400 SQL statements to be executed to the database, and I could not work out why.

Now, the answer seems simple now that I know what it is, but needless to say it took a few hrs to work out what the issue was, and then another few hrs to actually get a solution that I was happy with. But, I think I have a solution I can be happy, especially now that I have gotten the 400 or so SQL statements down to about 50 for the first load, and 5 (I am hoping I can get that down to 3) for every other load in the nHibernate session.

So, I hear you ask, what was causing this blow out?  It was the AutoMapper checking the value of the entity that was triggering the lazy loading of the collections and properties, which then resulted in every member in the object being loaded, then every member in every child entity, and so on until the entire entity tree was being loaded.  Now, I am sure that I might have a configuration setting not set up properly, or I might have something wrong with my entity definition, but from what I have found this is pretty standard behaviour.

Now for the fix.  It is really neat, and is done in the AutoMapper configuration when you create your maps between your entity and DTO object.  I had basic mappings set up (my DTO’s are closely aligned with my entities), so a sample mapping would be:

Mapper.CreateMap<Entity, EntityDto>();

Now, that is fine, but to stop the Lazy loading being triggered I needed to add a bit to the mapping definition when mapping the entity to the DTO (I don’t care about the mapping from the DTO to the entity, no data access there).  So my mapping from about became:

Mapper.CreateMap<Entity, EntityDto>()
 .ForMember(dest => dest.Collection, 
    opt => opt.Conditional(dest => NHibernateUtil.IsInitalized(dest.Collection));

As you can see, this simple change is nice and neat, and stops the AutoMapper triggering the Lazy Loading of the entities.  And, as we stop the lazy loading, we stop the extra unwanted and un-needed calls to the database.


Anyway, just thought I would mention it and hopefully help someone else having the same fun as I was.  Let me know your thoughts.

JOCU – The Alpha

I’ve been working on an OData reader in java for some time now, and I am ready to show people the first alpha.  There are some pieces missing, and I would prefer better ways of accessing some of the data.  But here it is.

The release only has the underived version of the JOCU project.  It allows for most of the functionality from the OData protocol (the main one missing is the data format, this uses XML data src as apposed to the json format).

Here is a code snipit I wrote that uses the API from the JAR library.

import java.sql.Timestamp;
import java.util.Date;
import java.util.List;

import lkoutzas.jocu.shared.AbstractCatelogueData;
import lkoutzas.jocu.shared.AbstractEntity;
import lkoutzas.jocu.underived.ODataEntity;
import lkoutzas.jocu.underived.ODataLink;
import lkoutzas.jocu.underived.ODataRepository;


public class RunJOCUDemo {

    public static void main(String[] args) {

        System.out.println("Welcome to the demo of the JOCU odata reader!!");
        System.out.print("Catelogues Start: ");
        System.out.println(new Timestamp(System.currentTimeMillis()));
        
        // create the odata repository
        ODataRepository oData = new ODataRepository();
        // set the URI for the location of the repository
        oData.SetURI("http://services.odata.org/OData/OData.svc/");
        // get oData Catelogue
        List<AbstractEntity> categlogues = oData.FetchODataCatelogues();
        System.out.print("End: ");
        System.out.println(new Timestamp(System.currentTimeMillis()));
        // dump out results to show it works...
        System.out.println("Catelogues...");
        for(int i=0;i<categlogues.size();i++)
        {
            AbstractEntity local = categlogues.get(i);
            System.out.println(local.getAttribute("href"));
        }
        System.out.println();
        System.out.print("Entities Start: ");
        System.out.println(new Timestamp(System.currentTimeMillis()));
        // create the odata repository
        ODataRepository oData2 = new ODataRepository();
        // set the URI for the location of the repository
        oData2.SetURI("http://services.odata.org/OData/OData.svc/");
        // set the catelogue for the oData repositpory
        oData2.SetCatelogue("Categories");
        // query or filter the data request (need to detail full list)
        oData2.getQuery().top("2").select("ID,Name");
        // get entities
        AbstractCatelogueData entities = oData2.FetchEntities();
        System.out.print("End: ");
        System.out.println(new Timestamp(System.currentTimeMillis()));
                
        System.out.println("entities...");
        for(int i=0;i<entities.getEntities().size();i++)
        {
            ODataEntity local = (ODataEntity) entities.getEntities().get(i);
            System.out.println(local.field("ID") + ": " + local.field("Name") + " links are: ");
            for(int j=0;j< local.getLinks().size();j++)
            {
                ODataLink odataLink = local.getLinks().get(j);
                System.out.println(odataLink.getTitle() + " - " + odataLink.getHref() + " ("+ odataLink.getRelationship()+")");                
            }
        }
    }

}

As you can see, the API is pretty easy to use and I think pretty good.  So, for the “bits not in the alpha”.

Firstly, there is a bug that will mean that XML structured elements (CDATA as an example) are not parsed correctly.  They get broken down into separate elements rather than a single blob.

Also, I would like to improve the manner that the data is being accessed.  It feels a bit clunky to me. I am not sure how I can improve it, but I would like to see what I can think of.

The last missing bit / bug is that the expanded entities within the querystring.  At the moment I think it would fail badly.  The API will allow it, but the data will likely either cause the call to fail or it will will be ignored.

Once these items are in the code, I am going to work on the derived version, which will allow strongly typed objects and (hopefully) reduce the size of the downloaded packet.

The link for the alpha is here.  Let me know your thoughts.

Rolling back a change set

Recently, I was working on a TSF Team Project project that had 2 branches.  I was continuously merging my trunk with each of these branches, as all three projects moved forward.  Recently I was given the go ahead to merge one of the branches into the trunk.  After checking and rechecking, I did this.

After about an hr after I had merged one of the projects into the trunk, I was, as usually happens, asked if I could make a change ASAP and release (in a way that would have the least impact on testing resources).  This meant that I needed release a version of the code that mirrored the current Production environment as a base with the necessary changes.  My first thought was that I would grab the change set, update the code, build on my local and release that.  However there was a gotcha, there was a requirement to have the build that was deployed done on the build server (with the TFS auditing of changes etc).

Anyways, I grabbed the required change set, made the changes, tested it locally, then checked it in, and released the result from the build server.  After checking that the release worked, I handed it over to the testers.  I then re-merged the code with the other 2 branches (luckily I hadn't deleted the one that I had been told to move into the trunk) so that they had the latest change.  Now, in TFS, merges use code on the server to merge, not code on your local (at least as far as I can tell).  As I was reviewing the changes and resolving the conflicts, I was seeing code from the trunk that included the branch I had merge into it.  Needless to say I got to wondering what had been built and then released to UAT.  I grabbed a tool to review the binaries that were in the release, and it was based on the project that I had merged into the trunk!  There was code there that I knew wouldn't be tested, and as such could not be released as this would increase the risk the change was raising (testing only the features of any change can mean that other impacts of the change are not identified until a full regression test is done).

So, I was left with a dilemma, how can I revert to a change set and release that change set, using the build server and all appropriate auditing in TFS, without having to manually remove all untested code and create a greater risk?  Then, after some googling, I came across a post by Mike Fourie, which details one of the new features in the August 2011 release of the Team Foundation Server Power Tools.  TFS 2010 has the ability, though the command line, to perform a roll back.  This extension brings that functionality into Visual Studio 2010 with a usable UI.  Let me just say that this saved my weekend from being an entire coding wreck.  I was able to roll back to the required version, then re-build and re-release only what was desired.  I wont re-write how it works, Mike does that well enough, but here are some links:

Mike’s Post: Using Rollback in the Team Foundation Server Power Tools

Team Foundation Server Power Tools August 2011

I hope this helps others out there who are wanting to (or having to) roll back code to a previous version on the server.