Programmer: Hero to All or Digital Masochist?

Ok so it hit me the other day when I was asking myself why I program. Basically I’ve hit that point in my career where I am starting to re-evaluate what the s— I’m doing and why I’m doing it. Actually it was more like me lamenting over my current path and I came to the conclusion that if I didn’t program for a living, I’d still do it as a hobby. To this the woman asked, “If you like it as a hobby, why do you hate programming?” This got me to thinking, do I hate this all the time? And the answer is no. I think this overworked bin of waste I call a blog is a testament to what I do love about programming. You know, the new stuff. The discovery. And yes (And you know it) the elation and self pleasing like act of “Yeah, I figured that out. I’m f—ing smart and stuff.” I even like the building and designing of systems (Well the non UI part since I have a restraining order that doesn’t allow me to be within 50 feet of UI design). Actually I really like that stuff.

Here’s the bad. When do I actually get a chance to do that? When do most of us ever get to do that? Problem is that most programming jobs don’t entail this. How do I know this? Well in my short 8 or so year career, I’ve had a lot of programming jobs. 9 to be exact. And about eh 50+ interviews with companies. So basically like a follower of “free love”, I’ve been around. In those jobs and interviews I’ve had 1 job and 3 possible ones where I wouldn’t have just been either:

  1. Maintenance Boy
  2. Legacy Avenger

Now you might think it’s because I suck. Well that could be a reason, but that would imply that the people I’ve worked with sucked since they were stuck doing the same thing, regardless of their experience. I can’t believe everyone I’ve worked with sucked, but I have no real proof. Then again, this isn’t being submitted to Fox New– eh The New York Ti– eh some scientific journal.

So with this I’m going out on a limb here and going to guess that the people not in the top 15% of the programming world are stuck doing tasks that involve:

  1. Updating old code
  2. Fixing old code
  3. Adding to old code
  4. Creating new things but under old standards and frameworks
  5. Spending time trying to figure out a web of stored procedures so complicated it would make Brian Greene spin. (His ENTIRE body)

And people do this everyday and a lot of them bitch about it but when pressed wouldn’t want to do anything else. Why? Because we hate ourselves! It’s simple f—ing psychology. When you hate yourself, you do things to keep that feeling of hate alive. You will be drawn to people who most likely cause us grief. You will be drawn to a job that causes pain. Think about it:

  1. In most companies, IT is the lowest rung on the ladder.
  2. People have no idea what we do which leads to horrible deadlines. Read: “It won’t take that long, it’s just HTML.”
  3. We work on systems that we didn’t build and the people who came before us didn’t have a lot of concern about someone else having to work on it.
  4. The stuff we work with can be really expensive and therefore most companies are years behind on IDEs, frameworks, ect
  5. In the high school we call the workplace, we’re basically the kid taped to the goal post.

And the best part is we’re described as problem solvers, which means right off the bat our job consists of cleaning up someone else’s f— ups or we’re expected to figure out the things that some committee of tool bags couldn’t get their collective head around.

I mean what sane person does this willingly? You know what the kicker is? We get some crazy high from when we actually do pull off some crazy impossible. Tell me how is that different than getting some kind of high after running a blade down your arm? We get pleasure from pain. That is our existence. We are sick puppies.

I’m hungry.

Singleton ObjectContext: The remix

I realized that when I posted this, I didn’t actually post my way of solving the singleton context idea. Well it’s not a real singleguy anymore in the strictest sense. It is still used by pretty much all querying BUT it is used every postback. How did I do this? With a little enginuity, brilliance, and time. (Read luck and constant pounding on the keyboard)

The old idea was to have a single context that was held in a static (Therefore the context was static). Couple problems:

  • All queries and updates will be sharing this context… for every user. Hrm. I can’t see anything wrong with Sally Starshine hitting the old update button and saving Dick McGurk’s changes. Nothing wrong with that all.
  • Any changes to an object in the context will stay in the context until the various ways of “resetting” a static object are used, regardless of being persisted to the database. Basically, if you changed the user.UserName = “YouIdiot”, “YouIdiot” will now show up anywhere you use that context… which is everywhere.

So as you can see, disaster. Now, where could I have gone from here? Well insane first, then I found a solution… Page Requests. You see, when a request is made there are two events fired of importance:

    protected void Application_BeginRequest(object sender, EventArgs e)
    {
    }

    protected void Application_EndRequest(object sender, EventArgs e)
    {
    }

Pretty snazy, right? Well these are fired with every request, so basically these are fired every postback… and then some. The next step I took was to make context creation and tear down methods. Something like on BeginRequest: If the context doesn’t exist, create and on EndRequest: If the context does exist, DESTROY. Well this worked at first… until I realized something. That cute little method BeginRequest fires on every request (Duh) meaning anytime the page requests an image. Hrm. That’s a lot of useless building right? Well it occurred to me the tear down on EndRequest was a good idea since it won’t do anything if the context doesn’t exist. No harm no foul. The problem was the BeginRequest. Fact is, the answer was stairing at me… I already had the build up method, I just had to call it when it mattered: First use. SO can you figure out what I did? I bet you can!

    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Text;
    using System.Web;

    public class EntityContext
    {
        private TISQLEntities _context;
        private static String MAIN_CONTEXT_KEY = "MainContext";

        public static TISQLEntities Context
        {
            get
            {
               if (HttpContext.Current.Items[MAIN_CONTEXT_KEY] == null)
                {
                    CreateContext();
                }

              return (TISQLEntities)HttpContext.Current.Items[MAIN_CONTEXT_KEY];
            }
        }

        private static void CreateContext()
        {
           HttpContext.Current.Items[MAIN_CONTEXT_KEY] = new TISQLEntities();
        }

        public static void RemoveContext()
       {
           if (HttpContext.Current.Items[MAIN_CONTEXT_KEY] != null)
           {
             ((TISQLEntities)HttpContext.Current.Items[MAIN_CONTEXT_KEY]).Dispose();
             HttpContext.Current.Items[MAIN_CONTEXT_KEY] = null;
            }
         }
    }

Idiot simple, as it would have to be coming from me. You might have seen that I’m holding it in the current HTTPContext. This is to hold the needed context for the current request. Yippee.

Now for the use (In the Global.asax.cs file)

    protected void Application_EndRequest(object sender, EventArgs e)
    {
        EntityContext.RemoveContext();
    }

So what happens? First time I use the context:

    EntityContext.context.SiteUser.Load();

The EntityContext class creates the context and goes to town. When the request is done, the EntityContext class removes said context.

Now on a side not, you might notice that when doing unit tests, there is no HTTPContext. This is a problem and involves one more step (That I’m not completely happy with right now) that actually takes the old Static idea and applies it. Now you might thing that I’m undoing everything I just posted, but in reality when you unit test, most likely you’ll be doing it on your computer and therefore you won’t be running into anyone else’s context. (Unlike a web site)

    private static String MAIN_CONTEXT_KEY = "MainContext";
    private static TISQLEntities _context;

    public static void RemoveContext()
    {
        if (HttpContext.Current != null && HttpContext.Current.Items[MAIN_CONTEXT_KEY] != null)
        {
            ((TISQLEntities)HttpContext.Current.Items[MAIN_CONTEXT_KEY]).Dispose();
            HttpContext.Current.Items[MAIN_CONTEXT_KEY] = null;
        }

        if(_context != null)
        {
          _context = null;
        }
    }

    public static TISQLEntities Context
    {
        get
        {
            if (HttpContext.Current == null)
            {
                if(_context == null)
                {
                    _context = new TISQLEntities();
                }
                return _context;
            }

            if(HttpContext.Current.Items[MAIN_CONTEXT_KEY] == null)
            {
                HttpContext.Current.Items[MAIN_CONTEXT_KEY] = new TISQLEntities();
            }

            return (TISQLEntities)HttpContext.Current.Items[MAIN_CONTEXT_KEY];
        }
    }

I don’t like this one fully, but for now it’s good. There has to be a better way though.

Programming Techincal Interviews: Why bother?

You know what’s awesome besides me? Technical interviews. Nothing beats being asked obscure questions about things that are rarely used while on the phone. I’ve been through enough of these stupid things (20+? over a short 7 years) to have a certain feeling about them. And just in case you are wondering, I don’t think I’ve ever failed one. (Even the online ones where I’ve consistently been above 80% of the country since the first one I took 5 years ago) I’m not bragging that I’m exceptional at programming, because I’m not. Probably average. What I am getting at is that I might have a decent view on how pointless these things are in the current state.

Insert Question Here

I can’t tell you how many times I’ve been asked things like:

“What is protected internal?” (Something I’ve never seen a company use)

“Is string an object or a structure?” (It thinks it’s a structure, so who cares?)

And my personal favorite:

“Which is better StringBuilder or String Concatenation?” (Yes?)

I get tired of these questions because everyone asks the same damned ones to the point where I feel like I could pre-record my answers on a tape recorder (Or whatever the kids use these days) and play them back while doing something more fun like washing my hair. (RUN ON SENTENCE!!!!1171) It almost puts me into this weird trance like state where my mind is off getting coffee while my body just churns out answers. Or even worse, when I try to discuss certain answers (Say the inevitable StringBuilder question) I’m met with the phone’s equivalent of a blank stare. AND IT NEVER CHANGES. I’ve heard at least these three questions at probably 90% of the ones I’ve done including at least two just within the last 4 months. Seriously, enough with difference between a datareader and a f—ing dataset. I think most people know this by now or could be informed in 10 seconds of getting the job. Or better yet, use a f—ing ORM.

The Google Era

The fun part about this is these interviews can pretty much be found in 5 minutes of a little searching. I am willing to bet if you take down the 30 most popular ones found and memorized, you’d be in the door. In fact, I pretty much know this since I’ve kind of sort of done a little studying before the interview (IE read parts of a book) to look good. And it sure worked. Now I have to admit there were other factors (Like my stunning good looks) but there were loads of people who bombed out on the technical interview due to missed answers. Even better, next time you have a technical interview, look up Microsoft Programming Interview C# and find the simple questions. One by one you mark off every one that is asked like those stupid car games that you mark off every state you see on a license plate. It will at least keep you interested. Hell, share with your friends and see who marks them all first. Put money on it.

The Recruiter Issue

Another problem that adds to the eh problem is that recruiters will tell you what you’ll be asked (Or at least point you in the direction) so that you can be ready for what’s coming. Why would they do that? Well it’s their job to make money and they make money by getting people in the door, especially if you have ANY personality. (Another thing that can completely override this precious technical interview.) I would say this is bad practice and companies should be made, but like actors and tabloids, this is a symbiotic relationship. How do I know this? Because I’ve actually had recruiters give me a list of questions the company SAID THEY WOULD ASK. What the f— is the point of asking me stuff I already know is coming? Yeah good way to make sure I don’t know what I’m talking about.

I’m just a programmer.

Here’s a though, next time your company does a technical interview, get someone who isn’t in the middle of a 70 hour week. In my experience, the one giving the interview really has better things to do, which is probably why the form letter questions are so popular. Can’t say I haven’t been in the situation when someone comes to me and says, “Hey we’re interviewing someone right now, could you get some technical questions together?” At which point there are two options, get questions off of the intarweb or put your head through your monitor to get out of it. And trust me, the second choice rarely works. Product? The same technical interview you went through last week… and last year…

Out with the old, Outsource with the new

The best so far though was a company that does these “technical interviews” (Read, they are technically an interview). Really? Outsourced interviews? I guess when I found out about this I thought that maybe MAYBE since someone was getting paid to do this, it might be interesting. Yeah not so much. For a long time I thought the prerequisites were:

  • Knew some programming.
  • Would rather be doing something else.

Turns out they can completely eliminate the first and keep the second. I honestly was asked questions like, “So you program in the c#?” and “So you have been using the object oriented programming?” This is a horrible situation for two reasons. One, the person taking the notes has no idea if you’re right or wrong and therefore could easily misquote you. Two, you will have to be put on suicide watch during the interview since at some point you’ll decide chewing your heart out is the only feasible way to escape.

Sigh, I mean honestly why do companies still bother with these? I mean if there’s any constant in the programming world, it’s that tools get hired no matter what and the rest of the company has to deal with them. Why is this? Because in the end, money is what matters. Recruiting companies will keep helping these guys through because it increases the chance of getting someone to fill the spot. Companies keep hiring them because usually they are about 1-2k cheaper per year. So in one word: Brilliant.

Entity Framework: Querying issue follow up.

                threedoors

So in THIS MIGHTY POST I asked why Entity Framework context likes to query the database despite the object (data row) already being loaded into the context. Well even though it’s not a perfect answer, Craig Stuntz had an answer at The O that gave some light to the situation:

context.SiteUser is an property of type ObjectQuery. When you execute an ObjectQuery, it will always hit the backing store. That’s what they do. If you don’t want to execute a database query, then don’t use an ObjectQuery.

Furthermore I could use GetObjectByKey:

GetObjectByKey tries to retrieve an object that has the specified EntityKey from the ObjectStateManager. If the object is currently not loaded into the object context, a query is executed in an attempt to return the object from the data source.

Which actually seems to me like how it should work naturally. After all, if it’s in the context and I am positive I don’t want to update the object from changes in the database, wouldn’t it make sense to not bother with the database at all? Seems like a wasted action. Again, I am guessing that the reason it does this is that it’s an all or nothing thing. It either does it all the time (IE query no matter the reason) or never. Grey area just doesn’t seem to fit Entity Framework design in this matter.

Entity Framework: Concurrency Mode and fun observations

Ok so you have this thing that you want to do and it involved stuff. And when you do that stuff you want something to happen. And when that happens you want to know that it happened and tell someone, “Hey I did stuff and something happened.” That, in essence, is what Concurrency Mode is for provided all this had to do with the Entity Framework and updating records.

Concurrency Mode allows you to make sure that nothing has changed in the database before or during the current save. Basically it checks the database to make sure the record being updated still is in the same condition it was when you loaded it to the context. If it isn’t, then an exception is thrown. (Maybe not the way I would prefer handling this situation, but hey I don’t work for the M) How do I get this to happen? Well it’s a pretty easy change, though it has an annoying short coming. First the change.

Open up the model browser (IE double click on the .edmx file) and select any property on any entity. Then view the properties.

concurencymode

And in the image you can see that there is a property surprisingly named “Concurrency Mode” and there are two options: Fixed and None. Guess which one I’m talking about in this post.

Now if I just left you with that, you’d have everything you need to know and you wouldn’t waste the next minute you’re going to waste on my findings. Good thing you aren’t smart enough to walk away.

You might wonder how the Entity Framework is able to do that, after all even I did and as we all know, I am genius.
Say you have a User entity where the UserName and MainEmail properties had Fixed Concurrency. Now suppose the old values of these were ‘oldValue’ and you just changed them (UI Side) to ‘HIHIHI’. At this point you want to save the changes. Well if you use profiler and a watch as it saves, you’ll see something like this:

exec sp_executesql
N'update [TIDBA].[TI_USER]
set
  [MainEmail] = @0,
  [UserName] = @1
where
  ((([UserID] = @2)
and
  ([MainEmail] = @3))
and
  ([UserName] = @4))
',N'@0 nchar(6),
@1 varchar(6),
@2 int,
@3 nchar(6),
@4 varchar(6)',
@0=N'HIHIHI',
@1='HIHIHI',
@2=1,
@3=N'oldValue',
@4='oldValue'

Which cleans up into:

update [TIDBA].[TI_USER]
set
  [MainEmail] = 'HIHIHI',
  [UserName] = 'HIHIHI'
where
  ((([UserID] = 1)
and
  ([MainEmail] = 'oldValue'))
and
  ([UserName] = 'oldValue'))

As you can see, the Entity Framework matches the originally loaded values against the database (Only on Fixed Concurrency properties) and sees if it can find a record. If it can’t, it means those values have changed. The exception follows.

Now besides the exception part (A bit much but can be handled), the only annoying thing is that you have to do this property by property. I don’t see a way yet to make it standard for the entire entity. Such is life.

Entity Framework: Odd things during querying

serverdatabasehitit1

So in THIS POST I talked about how querying worked on a conceptual level but turns out there is something going on that’s not expected. Remember how I said that if the object is in the context, the database won’t be hit? Turns out that isn’t true to an extent. With the help of profiler, I found outconfusing thing or two, and neither have to do with why this is was on the front page of CNN.

Say you for some reason want to select a user like so:

    SiteUser someUser = context.SiteUser.First(role => role.UserID == 1);

WOW THAT IS NEW AND AMAZING!!!117!

Right off the bat, I bet you can guess what happens. If not (You know, if you didn’t read THIS POST or you have difficulties with revolving doors), here’s the idea in script form:

            CONTEXT
    Am I having this Object?

Context looks into its bag, notices it doesn't have the object,
and then looks over at Database with confused look.

            DATABASE
   No but I gots it for you.

Database hands object to Context.  Context looks happy.

            CONTEXT
  I has a object now.

At this point, two things are obvious: I’ve lost it and Context now has a User with an UserID of one and it got this by querying the database. Now suppose for no real reason you want the same user. (Assume it is the same context and the user is already in the context.)

            CONTEXT
    Am I having this Object?

Context looks into his bag and pulls out the object.  Database walks over.

           CONTEXT
    You has object?

            DATABASE
   Yes but I gots it for you.

Database hands object to Context.  Context doesn't take it.

            CONTEXT
  I has it already.

So in this stunning display, we can see that even though the context already has the user, it still asks the database for the thing. How do I know this? Well I used profiler on both statements. What I thought would happen is on the first eh First it would hit the database, hydrate the object, and go on its merry. Second First would just grab it from the context and give it to me. Fact is, it STILL HITS THE DATABASE. Now the next possible idea is that it’s going to the database to see if the record has changed and then will update the object with any changes EXCEPT what has been changed on the object. Yeah not so much. (Although there is a way you can force that, but I’ll post that in the next post) Fact is, it really doesn’t do anything with it as long as you have the default settings. In fact, (FACT FACT FACT FACT) the default settings say that:

Objects that already exist in the object context are not loaded from the data source.
This is the default behavior for queries or when calling the Load method on an
EntityCollection<(Of <(TEntity>)>).

Seems kind of odd that by default something in the context will not be loaded if it’s already there but it still hits the database regardless. So what this default really means is that it may or may not hit the database, but any changes in the database will not be reflected in the object. It really doesn’t mean that the database won’t be queried. Seems kind of odd.

What not good enough? Fine, figure this out.

Entity Framework: Concepts and Headaches. Querying

So in the first part of this life changing tutorial, I explained what lazy loading was and how it worked with the Entity Framework. Now I wanted to get into querying/loading and how it’s handled. At least at a very simplistic angle. (Simplistic is what I do best. Day-oh!) Something that has to be understood is how the Entity Framework handles the hydrating/loading of objects and how it relates to the ObjectContext. Say you have the same User/Site example from the first part and you load a site:

    using(SomeEntities context = new SomeEntities ())
    {
       //where SomeEntities  : ObjectContext
       Site neededSite = context.Site.Where(site => site.ID = siteID);
    }

Ok so what happens here? Well basically the context will check itself to see if it holding said Site and if it isn’t, it will grab it from the database. This doesn’t seem like a big deal since it’s pretty obvious it won’t have the given Site yet since the context was just created. Now let’s get a silly example going for the sake of learning.

    using(SomeEntities context = new SomeEntities ())
    {
       //where SomeEntities  : ObjectContext
       Site neededSite = context.Site.Where(site => site.ID = siteID);
       neededSite.SiteName = someString;

       if(context.Site.Any(site => siteName == neededSite.SiteName))
       {
          //return error since the name already exists in the table.
       }

    }

Now as it is, this doesn’t seem too bad right? I change the name of the site and then see if that name is taken already in the database. If these seems ok to you it just means you don’t yet understand how the Entity Framework eh… works. The first time you go to get the Site, it fills it’s Site list with the Sites from the database, then checks the list for the one you want. It will then proceed to give you a reference to the Site in that list. Next time you do a query on the Sites list, it will NOT query the database but rather it will just query the Sites list it has in memory. Next, the line:

    neededSite.SiteName = someString;

Is updating the object in that list. Now you would think (If you are used to say not caching results from database queries) that the next query:

    context.Site.Any(site => siteName == neededSite.SiteName)

Would hit the database again and check the items there and make sure that SiteName doesn’t exist. But far as Entity Framework is concerned it already loaded that list, so it doesn’t need to hit the database again. This is good to save the performance hit of getting from the database but dangerous if you don’t understand this. Fact is, the context is just going to look at it’s cached list of Sites and run that query and guess what’s in that list? The object that you just changed. So basically that query will compare the object to itself at some point as it iterates through the list and yee haw it will find a Site that already has that SiteName… the one you just changed. Solution?

You can include the SiteID in the query:

    context.Sites
            .Any(
                  site => siteName == neededSite.SiteName
                  && site.SiteID != neededSite.SiteID
                 )

This way you know that you won’t compare the same object to itself.

OR You can create a new context if you really want to get a fresh look at the database. This will allow you to have a context with the new changes and a context pre changes so you can be sure you are comparing the object to a list without it.

Now you might look down the list of methods on the context and see the Refresh method. This might be temping because you might think that a refresh would give you what you want, a completely new list to compare against. There are two ways you can handle this:

     context.Refresh(RefreshMode.Store, context.Site);

Seems like this would be good since it basically means I want to completely restore the list from the database and clear out any changes I made in the list. Oh wait, what was that? ” clear out any changes I made in the list”. This means those changes we made to the object, yeah gone. So now the:

    context.Sites
           .Any(
                  site => siteName == neededSite.SiteName
                  && site.SiteID != neededSite.SiteID
                )

Query is hosed because the neededSite.SiteName has been reverted to whatever was in the database originally.

You could try this:

     context.Refresh(RefreshMode.ClientWins, context.Site);

In which any changes made to the objects will overwrite any information being brought in from the database. Hmm, 6 of one and a half dozen of the other. This just brings us back to the same problem. The list will still contain the changes to the object and therefore we will once again compare the object to itself.

Now you might think that maybe you should just check the list BEFORE applying the changes to the object, and that would be a good way of going about it:

    using(SomeEntities context = new SomeEntities ())
    {
       //where SomeEntities  : ObjectContext
       Site neededSite = context.Site.Where(site => site.ID = siteID);

       if(context.Site.Any(site => siteName == someString))
       {
          //return error since the name already exists in the table.
       }
       else
       {
          neededSite.SiteName = someString;
          //Continue or save
       }
    }

This would work since you are checking the list before the object has been changed. This might work if you do your saving in the same layer that you have your UI, but if you do something like this:

    ...
    Site someSite = Site.GetSiteById(id);
    someSite.SiteName = txtSiteName.Text;
    someSite.Save();
    ...

In this example, I have created a Save method on the Site object that will take care of validation and saving all in one. It also means that I either am sharing a context between the GetSiteId method and the Save method, or that I am using two contexts. If it’s the latter, then it won’t matter since the context in the Save method will not “own” the current someSite object. (And therefore will not have the changes to the someSite object reflected in its list) However, if they do share the same context then you will run into the above problem.

In the next post, I’ll talk about how to share a context… which I won’t try to sell you as the right thing to do. Just something to think about.

Entity Framework: Concepts and headaches. Lazy Loading

So when I wrote this and this I didn’t really have a precursor to some of the concepts in the posts so I figured I’d get them out of the way now since I’ll be posting a bunch on the Entity Framework.

First off is lazy loading. Now I could put the obligatory stupid joke here that gives some kind of novel, but incorrect, explanation of the phrase (Like say making someone else wash your clothes) but I so much better than that. So what is lazy loading? Simply put it’s not getting something until you need it. Kind of like “If it ain’t broke then don’t fix it” instead you trade “broke” with “needed” and “fix” with “get”. So it’s really not like that phrase. It is however, when talking about objects being hydrated (ie loaded) from some kind of storage (ie database) in a program written by some idiot. (ie me) Let’s say you have a User table and a Site table in which there are many Users to one Site. Now with an ORM this will be represented by an User object, a Site object, and a property on User that is of type Site. It would look something like this:

    public class User
    {
      private Site _site = null;

      public Site ParentSite
      {
         get
         {
            if(_site == null)
            {
               _site = SomeMethodToGetSite();
            }

            return _site;
         }
      }
    }

When you load the User from storage, initially the Site object on the User object is null. This is done because if you don’t need the Site yet, why take up space until you do? This is the concept of lazy loading. Now in most ORMs, the Site would automatically be hydrated the first time the Site property was accessed. Entity Framework is slightly more complicated when dealing with the many to many or one to many situation.

This happens when you have a Users list on the Site object that basically represents every User in the User table that has the same SiteID as the Site in question. OR maybe you have a hanging table UserSite that allows for one Site to have many Users and one User to have many Sites. Either way, you will be left with a collection that represents this relationship. (Users list on the Site object) Now say you do this:

  Site someSite = LoadSiteByID(siteID);

and then you try to do this:

  someGrid.DataSource = someSite.Users;
  someGrid.DataBind();

When the page loads, there are no records in the grid. In a normal ORM this wouldn’t be a problem. It would see that you are accessing the .Users property and hit the database to fill the list. Entity Framework requires you to take one more step in this case.

  someGrid.DataSource = someSite.Users.Load();

Not that big of a deal. Now there is a check even to see if it is loaded in the first place:

  order.Users.IsLoaded

This is a boolean property that says true when it has been loaded. Next post I’ll hit on what happens when you query and how that relates to this situation.

Quick Hit: Hiding Horizontal or Vertical scroll using CSS

If nothing else the motto for this site is, “Why was this written?” but sometimes it can also be, “I bypass the middle man and pass the savings on to you.” In this case, it has to do with a really simple way to show only on scroll bar on a section be it a div, span, pre tag, ect. In fact, I actually used it to for this site.

Here’s the problem, you have a section that you want to only show the horizontal scroll bar. Now the scroll bar is usually set with the overflow keyword in css:

  overflow:auto;

But what does this do? Well if the section you have is larger than its parent (Say a pre section in a set width div), both scroll bars come up. Sometimes that’s not a bad thing but sometimes it looks really annoying if you only have two lines in it like:
bat_scroll1
Since it will automatically force both scroll bars. And on top of that, the scroll bars themselves now take up space and essentially cover up some of that second line. Well there’s two ways you can go about this in order to at least allow for everything to be seen without a verticle scroll.

1)

You can use the overflow-x and overflow-y keywords:

  {
    overflow-y:hidden;
    overflow-x:auto;
  }

What this does is completely hides the verticle scroll bar. Now this will work very well if you have sections that are of a specific height. Problem is if the height isn’t set specifically, it will just not show the parts that would normally need the verticle scroll for. (Happens sometimes)

bat_scroll2

This brings us to the second solution:

B)

Padding.

  padding:8px 0px 40px 0px;
  overflow-x:auto;
  overflow-y:hidden;

Really simple addition that will basically push the bottom of the container down so that the writing that was being hidden before (Because the scroll bar didn’t exist) is now pushed upwards causing no loss of stuff.

bat_scroll3

As you can see, now everything can be… eh seen. Sure you get that annoying bit of space, but the 40px I’m using could be a bit of overkill. You really just have to shoot for a number that allows the bottom to be shown. But hey, life is tough.