Skip to content

The problem on deleting record using and paging GridDataTable and updating records on mapped collections in NHibernate

December 12, 2012

Today, has been a hectic day, involving NHibernate and the rather mystical things it does. Then number of hours trying to demystify the problems can be long and rather cumbersome. Here are the situations found.

Firstly, looking at the issue of mapped collections in NHibernate, if you view a large data set from a table say 10000 records, you may encounter a problem where updating one field of one record in that dataset, it seems from earlier this week that everything NHibernate retrieves gets stored in the first level cache, but for larger record data sets if the mapping lazy=”false” has been removed, it will retrieve a simple select all of that table in this first level cache. However what I later found out was that NHibernate will loop through one by one of the record by select and update behind the scenes on the first level cache if you update the one single record observing through SQL Profiler. Initially I had thought it may be a mapping issue, and till now, I think it may be, but after simple trial and error, if NHibernate doesn’t have a Primary Key set (if you had copied using Import Data), NHibernate may hang for a long period of time for whatever reason I still don’t know, so if you place the PK it solved the issue, hence it relies heavily on indexing!

Secondly, it had been something discover today is that ASP.NET cannot handle the DataGridCommandEventArgs well  on the delete command based on setting your own ButtonColumn in the DataTable, for some reason it doesn’t point to the correct index whilst the edit command does! Here is the code below: –

// Now add the HyperLink column to delete user
ButtonColumn deleteButtonColumn = new ButtonColumn();
deleteButtonColumn.CommandName = “delete”;
deleteButtonColumn.DataTextField = “Username”;
deleteButtonColumn.DataTextFormatString = “delete”;
deleteButtonColumn.Text = “delete”;
deleteButtonColumn.ButtonType = ButtonColumnType.LinkButton;
deleteButtonColumn.ItemStyle.Width = 20;
deleteButtonColumn.Visible = false;

……………………

tbl.DeleteCommand += new DataGridCommandEventHandler(this.DeleteItem);

……………………

protected void DeleteItem(object sender, DataGridCommandEventArgs e)

{
if (e.CommandName == “delete”)
{
DataGridItem container = (DataGridItem)e.Item;
string userID = container.Cells[0].Text;
string userName = container.Cells[1].Text;

User user = User.GetUserByUsername(userName);

if (user != null)
{
user.Deleted = true;
SessionFactoryContext.SaveOrUpdate(user);
SessionFactoryContext.Flush();

}

}

}

If you have paged your GridDataTable with the use of displaying a set number of records to be shown on the GridDataTable at one time, you may have seen that the method protected void DeleteItem(object sender, DataGridCommandEventArgs e) DOES NOT point to the correct record after subsequent records (e.g. 2nd or 3rd page), it still simply refers to the first set of records from the first page, it may be a databinding issue but with the same templating for the edit command, it is a worry.

Or it may be an issue with the DataGridCommandEventHandler, where it may rely on a postback to retrieve the new DataGrid? I had added this.DeleteItem to point to the current instance of the class, but that didn’t solve the problem as shown: –

tbl.DeleteCommand += new DataGridCommandEventHandler(this.DeleteItem);

The simple solution is simply point to the record and delete using a accessor directly, but would be nice to solve this problem.

Anyway rant over!

Advertisements

From → Uncategorized

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: