PDC05: Paneldebatt om LINQ-projektet

Denna session hölls av bland annat Don Box och Anders Hejlsberg. Nedan följer de frågor som ställdes av publiken till panelen där jag försökt samanfatta svaren. Svaren är inte ordagrant översatta och innehåller mina tolkningar av svaren i vissa fall då det ibland blev stora utläggningar som jag inte återger.

Vilken prestandaskillnad kommer det att vara mellan DLINQ och lagrade procedurer med avseende på CRUD-operationer?

Man har inte jobbat med prestanda ännu. Men det som ska skilja i slutprodukten är endast kostnaden för att transformera data från databasen till starkt typade klasser.

Hur hanterar man HTML som inte är välformaterad när man läser in det med XLINK?

För stunden så hanteras detta inte alls. Men det finns ett litet verktyg som man kan ladda ner och använda som liknar HTMLTidy. Kanske kommer detta in i ramverket så småningom.

Varför har man inte lagt till LINQ till språken och andra vidareutvecklingar tidigare?

Man kan alltid lägga till funktionalitet men aldrig ta bort, detta innebär att man är extra försiktig med att lägga till utökningar av språk.

Varför lägger man till LINQ, risken är stor att detta kan missbrukas?

Sant, ny teknik kan alltid missbrukas om man inte vet när och hur man ska använda den. Men ser man till det stora hela så innebär det att man behöver lära sig mindre saker för att kunna utföra vissa uppgifter vilket uppväger det hela.

Kommer LINQ framöver att innehålla mappningar precis som Object Spaces var tänkt?

Inte som det ser ut nu, så fort man lägger till mappningar så ökar komplexiteten. Målet är att släppa enkla tillägg som gör det enkelt att exempelvis hämta data från en XML-fil, skapa en objektmodell utifrån denna och göra det möjligt att använda denna modell.

Kan man använda LINQ mot DataSet? När blir DataSet en in-memory databas?

Nej, inte nu, men det kommer.

Så snart DataSet kan spara data så kommer dessa att kunna agera som in-memorydatabaser.

Vilken typ av feedback har man fått från SQL-gänget och SQL-communityn kring LINQ?

Vi jobbar dagligen med SQL-gänget så där är det lugnt. Vi förstår varandra och utbyter löpande information.

Ser man till SQL 2005 och CLR-integrationen så är förhoppningen framöver att man i databasen ska kunna använda frågor av typen LINQ istället för ADO.NET och T-SQL. Det är detta som är nästa steg.

Vilka är era drömmar om hur LINQ ska användas bortom SQL och XML?

Att ha transaktioner med överallt. Att SQL-server och JIT hör ihop och kan nyttja funktionalitet från varandra.Att kunna använda in-memorydatabaser och skjuta frågor.

Att kunna ha starkt typad programmering med XLINQ.

Hur hanterar man strömmar, LOBs? Är LINQ en ersättare till ADO.NET?

Man skapa en fråga och först när man frågar efter en BLOB i objektet så hämtas det, då kan man jacka in och ta strömmen av data.

DLINQ ligger ovanpå ADO.NET, det är ingen ersättare!

Hur är det med concurrency och C#?

Det som finns idag räcker långt. Men Lambda Expressions gör det möjligt att distribuera ut kod som parametrar. Möjligheten med detta är att man kan skapa in-memory transaktioner där kod distribueras ut och knyts ihop i en transaktion.

Hur är det med arv av tabeller i en databas?

Initialt så kommer endast en mappning finnas där en tabell blir ett objekt.

I Object Spaces jobbade man med arv i flera nivåer vilket bara blev en stor soppa. Svårt att förstå och svårt att underhålla.

Vi lyssnar dock på er feedback och vet att detta är något ni önskar.

Är Lambda Expressions serialiserbara?

Njaaa…. Med hjälp av Reflection kan man skapa kod så det går att lösa det, men just nu tittar man på lösningar kring detta.

Jag jobbar både i VB och i C# och då är det härligt om syntaxen liknar varandra. Men i VB ser DLINQ ut som T-SQL, varför?

Det finns flera anledningar till detta. Problemet med T-SQL är att frågan inte återspeglar hur frågan exekveras. Resultatet av T-SQL är "flat". I LINQ så kan det vara hierarkier då indata kan komma från en databas eller ett XML-dokument. Det är därför som C# har ”From” först. Vi ska ju leva med detta i 20 år farmöver minst.

I VB så gjorde vi valet att ha ”Select” först då vi tror att VB-utvecklare är vana vid notationen i T-SQL och vill underlätta för dem. Vi är tidigt ute och kanske ändrar vi detta, men vi ville testa hur det emottogs ute i Communityn.

Intuitivt så är det bättre med select … from då den som läser koden oftast bara är intresserad av vad som hämtas upp, inte från var och hur.

Kommer LINQ till .NET Compact Framework?

Ja, delar kommer nog troligen framöver.

Man kommer att jobba på att LINQ-frågor ska kunna skapa T-SQL som utvecklaren kan köra mot en databas.

Hur ska in-memoryfrågor optimeras framöver när man har en kollektion?

Idag sker allt med linjära skanningar. Det finns inga index att använda osv. Det ska vara enkelt. Risken är att i de fall man har mycket data och skulle kunna dra nytta av index så skulle detta slå mot de enklare frågorna om det alltid skulle ske en koll av Queryplans osv.

När man joinar databasdata och in-memory så har man två val, antingen hämtar man upp från databasen eller tvärtom. Som det ser ut nu lyfter vi upp data ur databasen.

Vi planerar inte att tråda joins mellan olika datastrukturer.

Hur hanteras Update, Delete, Insert i DLINQ?

Den helautomatiska vägen är dynamiskt skapad T-SQL med ”Optimistic Concurrency” där vi håller reda på de gamla värdena.

Det är också möjligt att själv specificera vilka lagrade procedurer som ska användas om man så önskar.

I nya SQL Server 2005 finns den nya datatypen XML. Hanteras denna av DLINQ?

Idag hanteras denna inte, förhoppningen är att DLINQ och XLINQ ska kunna utbyta information i framtiden och då får vi också stöd för XML-datatypen.