Hi, Frans. Since Yukon will actually host the CLR, what sort of integration will we see there in the next version of LLBLGen (if you've had the time to think that far ahead)? Can LLBLGen provide the same type of integration as ObjectSpaces once promised? I haven't fooled around with it myself (I have the beta, just haven't opened it up yet), but I was just curious.

Also, I understand that Yukon will provide a basic "DataChanged" event that will fire when a given query's resultset changes. It would be great if LLBLGen could handle that event and provide auto-synching behavior...

Jeff...

Its also going to do other crazy things like letting you define your own data page size. As well as having new data types, i.e. XML, Ink, date, and time are all "rumored" to be new data types.

Devildog74 wrote:

...as well as having new data types, i.e. XML, Ink, date, and time are all "rumored" to be new data types.

!!! They're going to split out date and time! <passes out> Do you know if it's in the currently available beta? Hmmm...I'm wondering if they're going to add a new base type in .NET to match it. Ooooo...

Jeff...

jeffreygg wrote:

Hi, Frans. Since Yukon will actually host the CLR, what sort of integration will we see there in the next version of LLBLGen (if you've had the time to think that far ahead)?

For yukon a new driver and DQE will be made, which allows the code to run in-process with the database. Also, as Yukon is part of the .NET 2.0 timeframe, the driver/code will utilize .NET 2.0's features like generics, partial classes and the like. I'm not sure how MS will incorporate user defined types into client side .NET code, but if it's as simple as referencing an assembly it will be supported.

Can LLBLGen provide the same type of integration as ObjectSpaces once promised? I haven't fooled around with it myself (I have the beta, just haven't opened it up yet), but I was just curious.

Objectspaces was not that integrated with yukon, it just uses yukon specific features to update caches and used sqlserver specific features as a core functionality.

Also, I understand that Yukon will provide a basic "DataChanged" event that will fire when a given query's resultset changes. It would be great if LLBLGen could handle that event and provide auto-synching behavior... Jeff...

Yeah I read about that too, however one thing which told me it will not be used outside the demo-room is that the interface for that service is in..... ASP.NET. I don't know if there are SqlClient interfaces planned, but if it isn't, it's a technology cooked up by a marketeer and implemented by a 1st grader.

Nevertheless, it sounds ok, but it will be very intensive for network and database. Looking at the complex versioning they've implemented for data during transactions (which is IMHO one of the key features but no-one talks about it, no pretty pictures ...) I fear that propagating these changes to datarows outside the database will be even more complex: because when to propagate a change? When the row is updated during a transaction? or when the transaction is complete? But what if 2 transactions are updating the same row (which can happen in multi-versioning) ? Or are batched updates every minute more appropriate? And my concern: what does it say when a service outside the database gets a signal: "the data has been changed"? to me it doesn't say much, as in the delay it takes to send that message, the change can be undone for example. Or after the row is fetched again, the row can be updated again, which illustrates the point that data outside the database will ALWAYS be stale date, no matter how much feedback services you install. (and big databases will burn down to the ground if they will send messages out when every row changes... so a lot of DBA's will turn it off)

jeffreygg wrote:

Devildog74 wrote:

...as well as having new data types, i.e. XML, Ink, date, and time are all "rumored" to be new data types.

!!! They're going to split out date and time! <passes out> Do you know if it's in the currently available beta? Hmmm...I'm wondering if they're going to add a new base type in .NET to match it. Ooooo...

Jeff...

The Date/Time types were dropped late in Beta 1. You will be able to write your own types but there will be no built-in Date and Time types. This is actually a good thing because the way they were doing it was not the best way and it is better for them to drop it then do it wrong.

Frans,

when the SQL server 2005 version of the LLBLGenPro will be realesed?

We are at the beginning of the new project, and would be very happy, if we could plan the application's dataacccess on the basis of LLBLGen.

Moreover the Microsoft dropped the ObjectSpaces from the Yukon B1, so your excellent product would be a very valuable choice for everybody, who want a very usable ORM.

Thanks,

Gabor

Gabor wrote:

Frans,

when the SQL server 2005 version of the LLBLGenPro will be realesed?

We are at the beginning of the new project, and would be very happy, if we could plan the application's dataacccess on the basis of LLBLGen.

Moreover the Microsoft dropped the ObjectSpaces from the Yukon B1, so your excellent product would be a very valuable choice for everybody, who want a very usable ORM.

v1.0.2005.1, now in beta, has support for Sqlserver 2005, for the new Xml type, for the larger Varchar/varbinary types etc., but not for UDT's and CLR types.

This version is released very soon. v2.0 of LLBLGen Pro, planned for the end of this year, will have support for Sqlserver UDT's.