Async CTP: welcome new keywords ;-)

fino a ieri non se ne poteva parlare, figo:

class Worker
{
	public async Task ExecuteAsyn( T value )
	{
		var task = await TaskEx.Run( () => 
		{
			Thread.Sleep( 1000 );
			return value; 
		} );
 
		return task;
	}
}

async e await mi stanno molto simpatiche, molto
.m

Prodotti per Mac su MSDN

Interessante…almeno qualcuno la pianterà di usare solo quelle robe tipo iWorks…
.m

A new kid on the block: it.comp.dotnet

Faccio eco a Raff per “pubblicizzare” la nascita di un nuovo newsgroup: it.comp.dotnet
See you there
.m

Finalmente! VS2010 Fix Context Menu Scroll

Per tutti quelli che mi hanno fatto una “capa tanta” con sta menata e per il sottoscritto che un po’ la “capa tanta” se l’è fatta da solo , è uscita una hotfix per risolvere il fastidiosetto problema che i menù contestuali di VS2010 avevano le scrollbar anche quando non servivano:

We’ve been looking into the widely-reported problem with Visual Studio 2010 where context menus contain scrollbars even when there is sufficient screen real estate to show the menu without one. We’re pleased to announce that there are patches available for Visual Studio and Windows Presentation Foundation that fix this problem. You will need to install both patches to fix this issue

1. Visual Studio 2010 patch: http://code.msdn.microsoft.com/KB2345133
2. Windows Presentation Foundation 4.0 patch: http://code.msdn.microsoft.com/KB2413613
   1. X86: NDP40-KB2413613-x86.exe.
   2. X64: NDP40-KB2413613-x64.exe.

If you have any additional questions, post here (on the blog comment section) and we will follow up to ensure a bug is filed or a solution is found.  

Fonte: http://blogs.msdn.com/b/visualstudio/archive/2010/10/14/hotfixes-available-for-scrolling-context-menu-problem.aspx
.m

Yes!

.m

NHibernate: caricare un albero in un singolo round-trip con il db

Supponiamo di avere una entità del dominio che rappresenta un albero, albero mappato e persistito con NHibernate,  e abbiamo bisogno di caricare tutto l’albero in un singolo round-trip con il db.

La soluzione proposta da Ayende è indubbiamente ottima e funzionale, e non è obbligatorio usare hql funziona con qualsiasi sistema di query venga usato.

var tree = provider.CreateCriteria<Branch>()
	.List<Branch>()
	.Where( z => z.Parent == null )
	.ToList();

Quello che succede è decisamente figoso, in sostanza quello che fate è limitarvi a caricare tutti i dati della tabella e lasciare che sia l’Identity Map della ISession a fare il resto del giochetto per voi; quello che non viene tenuto conto nella soluzione proposta, ma nessuno l’ha chiesto del resto, è la possibilità che in fase di query venga imposto un filtro: voglio l’albero con i soli nodi il cui nome inizia per “P”:

var tree = provider.CreateCriteria<Branch>()
	.Add( Restrictions.Like( "Name", "P%", MatchMode.Anywhere ) )
       .List<Branch>()
	.Where( z => z.Parent == null )
	.ToList();

Implementando la “Restriction” succede che il primo livello viene correttamente filtrato ma per i figli NHibernate emette degli statement sql che tornano sul db nonostante al primo giro i dati vengano filtrati correttamente, ragionandoci su ci rendiamo conto che alla fine ha ragione lui e il “problema” è abbastanza semplice da aggirare:

var tree = provider.CreateCriteria<Branch>()
	.SetResultTransformer( Transformers.DistinctRootEntity )
	.CreateAlias( "ChildBranches", "cb", JoinType.LeftOuterJoin )
	.Add( Restrictions.Like( "Name", "P%", MatchMode.Anywhere ) )
       .Add( Restrictions.Like( "cb.Name", "P%", MatchMode.Anywhere ) )
       .List<Branch>()
       .Where( z => z.Parent == null )
       .ToList();

Basta cioè propagare la condizione anche ai figli, a questo punto scopriamo che la ISession di NHibernate è veramente smart ed esegue correttamente il caricamento dell’albero facendo sempre e solo un round-trip verso il db.
.m