1
Vote

Linq Syntax for Manipulating Table data

description

Just thinking outloud,
 
how about some form of linq syntax for manipulating data and moving between tables.

comments

grava wrote Mar 30, 2008 at 2:34 PM

Have to move the targeted framwork to 3.5, don't know much of Linq, but it will be suitable in order to have enabled features like Object Initialization, Automatic properties and perhaps some lambda expression useful for remove that delegate with anonymous methods.

Don't know much about LINQ ... try to toy with it !

rikware wrote Mar 31, 2008 at 1:00 AM

How will this be different from LINQ to SQL? I think we need to define some goals for what RikMigrations will and won't aim to do. The new data insertion stuff is good and I think it fits within the typical use of migrations, but I don't think we need a full data manipulation library since that's already available in many other projects.

re: moving to 3.5, I think it's best to avoid that for the moment to keep the library open for use in 2.0. However, it may be worth moving the compilation up to VS2008 which will allow us to use the features you mention, while still targeting 2.0. The downsides are that it restricts who can contribute and compile the library themselves. Let's at least see if everybody on the current team has access to 2008.

rikware wrote Mar 31, 2008 at 1:03 AM

Just to clarify - VS2008 will enable use of "Object Initialization, Automatic properties and perhaps some lambda expression useful for remove that delegate with anonymous methods" (of course, it's just syntactic sugar. We still end up with anonymous methods. They're just expressed as lambda expressions now).

AndyStewart wrote Mar 31, 2008 at 8:59 AM

We could have a seperate assembly for linq extentions, this way the project can still be used on 2 without 3.5, it needs more thought but I think it can be achieved while having backwards capability with .net 2 as nHibernate do this with linq to nhibernate.

The problem with linq to sql apart from it generating tonnes of code, is that it wont stay in sync with current dbmigration. Thats why I think if possible it maybe nice to add a simple linq to sql, syntax that parses straight to sql. As you say it would only be syntactic sugary but maybe nice, and it's another abstraction away from straight sql, which should intheory increase our database independance.

So for example

_db.CreateStoredProc("Name", from row in _db.Table["tablename"] where row["Id"] = 1);
_db.Delete(from row in _db.Table["tablename"] where row["Id"] = 1);

This obviously needs more thought. I don't even know if this can be achieved.

wrote Feb 13, 2013 at 12:20 AM