Magiq: Next steps – different approach
Back to the Magiq game!
I started to play with Entity Framework 4 and realized some stuff is not possible the way it was designed. It has to do with the way EF4 manages Lazy collections.
In Linq-to-sql and NHibernate, the collection itself has the property of being lazy, materializing all the objects when you iterate it. For example, in Linq-to-sql collections are EntitySets. Because of this, you can do this:
parent.Children.Delete(x => x.SomeCondition);
This is because the Children collection contains all the information needed:
- The parent object instance, for getting the Id
- The collection name
Sadly, EntityFramework handles this feature in a different way: Is the parent object the lazy one and the collection is populated when you access the collection propery and not when you iterate it. Because of that, in the moment you do parent.Children you have executed the query in the database.
This lead us to have a different API, that avoid accessing the collection property. What I thought is:
parent.Delete(p => p.Children.Where(x => x.SomeCondition));
It’s not so bad, I must Say, and it also let us do things like
parent.Delete(p => p.SomeObjectInTheMiddle.Children.Where(x => x.SomeCondition));
without executing the query for getting the SomeObjectInTheMiddle instance.
Also, I give up with Magiq-to-NHibernate, at least for a while. NHibernate has huge features, it let you map your classes in thousand of different ways, and that is awesome. But also it makes it really complicated to work with. And since NHibernate already has mass operation support, it makes sense to stop worring. At least, as I said before, for a while.
So, I will be working on changing the Query API and only for Linq-to-Sql and Entity Framework. Everyone is welcome to contribute implementations for other ORMs.
Next step: Changing the API