Otis,

Do you have any updated on when table inheritance will be supported in the code? I'm using the adapter model and need to be able to make a single entity from two tables that have a one to one relationship.

I can't give you a release date.

The next 2 updates will be: - designer upgrade to add better refreshing capabilities, naming functionality, multi-join in typed lists, multi-catalog/schema in projects and some other minor things. - overall upgrade with main new designer functionality and new runtime functionality.

The first is scheduled for january, the second for a few months afterwards. It is very likely the second upgrade will have inheritance (2 forms: 1 table for all entities and per entity a table with the unique fields per entity) but it depends on how much work it is for implementing it into the runtime structures. Very likely inheritance will have some limitations like no polymorphism over relations, but that's not set in stone yet.

The second upgrade will be the last one of the current code base. So I hope to add inheritance to the pack. I'm not sure if I'll add new drivers for other databases than the current crop, except SqlCE, which will be added in the second upgrade phase.

Otis wrote:

I can't give you a release date.

The next 2 updates will be: - designer upgrade to add better refreshing capabilities, naming functionality, multi-join in typed lists, multi-catalog/schema in projects and some other minor things. - overall upgrade with main new designer functionality and new runtime functionality.

The first is scheduled for january, the second for a few months afterwards. It is very likely the second upgrade will have inheritance (2 forms: 1 table for all entities and per entity a table with the unique fields per entity) but it depends on how much work it is for implementing it into the runtime structures.

Woohoo!

The second upgrade will be the last one of the current code base. So I hope to add inheritance to the pack. I'm not sure if I'll add new drivers for other databases than the current crop, except SqlCE, which will be added in the second upgrade phase.

Woohoo!

So, if you're ready, can you tell us a little bit about the next product/release?

Jeff...

jeffreygg wrote:

The second upgrade will be the last one of the current code base. So I hope to add inheritance to the pack. I'm not sure if I'll add new drivers for other databases than the current crop, except SqlCE, which will be added in the second upgrade phase.

Woohoo!

So, if you're ready, can you tell us a little bit about the next product/release?

All that it will use an upgrade of the current designer (thus not a complete new designer) and the runtime code for .NET 2.0 will be a single codebase with selfservicing being a wrapper around adapter. (i.e. internally it uses a single adapter or per context a single adapter). Also due to the partial classes, two-class scenario configs will be unnecessary and due to generics I hope to move as much code to the runtime libs as possible

But that's about what's decided now. I haven't payed much attention yet to .NET 2.0, as Microsoft changes a lot during beta 1 and beta 2, so I'll start designing when beta 2 is out for .NET 2.0 and the plan is to have the product ready when .NET 2.0 is released in august 2005 (or thereabout)

Otis wrote:

All that it will use an upgrade of the current designer (thus not a complete new designer) and the runtime code for .NET 2.0 will be a single codebase with selfservicing being a wrapper around adapter. (i.e. internally it uses a single adapter or per context a single adapter).

Awesome! Since we're on the subject of Self-servicing vs Adapter, I was curious...is it possible to get a Self-Servicing to Adapter code converter? The other question was whether when you "combine" Self-Servicing with Adapter whether you'll also be able to eliminate having to maintain 2 entity types, 2 collections, 2 EntityType enums, etc...

Also due to the partial classes, two-class scenario configs will be unnecessary and due to generics I hope to move as much code to the runtime libs as possible

mmmm.....generics....

Is it possible/advisable to get some sort of continuous integration? ie., if I add an entity via the designer (preferably in VS), the code is auto-updated/generated... this would be very nice for things like typed lists, too...

Jeff...

jeffreygg wrote:

Otis wrote:

All that it will use an upgrade of the current designer (thus not a complete new designer) and the runtime code for .NET 2.0 will be a single codebase with selfservicing being a wrapper around adapter. (i.e. internally it uses a single adapter or per context a single adapter).

Awesome! Since we're on the subject of Self-servicing vs Adapter, I was curious...is it possible to get a Self-Servicing to Adapter code converter?

No, that's impossible. Not that it is hard to convert the code, it's hard to create a C#/VB.NET parser which converts that code.

The other question was whether when you "combine" Self-Servicing with Adapter whether you'll also be able to eliminate having to maintain 2 entity types, 2 collections, 2 EntityType enums, etc...

Most of the templates now is not that complex, maintaining it is not the hard part, the main issue is below the surface, in the runtime libraries. Now the 2 paradigms share very little code, and with having adapter as the base and selfservicing a wrapper around adapter, it will be a different scenario. In fact, I hope to have adapter's code almost all in the runtime lib and selfservicing just a little bit of template work, but not much.

I'll definitely keep the two paradigms, as they're so different from each other, in philosophy, that dropping one in favor of the other would be a loss.

Also due to the partial classes, two-class scenario configs will be unnecessary and due to generics I hope to move as much code to the runtime libs as possible

mmmm.....generics....

Is it possible/advisable to get some sort of continuous integration? ie., if I add an entity via the designer (preferably in VS), the code is auto-updated/generated... this would be very nice for things like typed lists, too... Jeff...

Although in theory there is a point of having them, I don't think in this particular situation it's what you want. The main reason is that it isn't a wordprocessor we're dealing with, but a complex system which requires a sequence of actions before the user will say: "yes, this is what I wanted" and hits save/generate. So before that point is reached, it's not that efficient to start some output action along the way to that point, IMHO. Also because code generation is not free: it takes time to generate code, and the more entities, the more time it takes.

Thanks, Frans.

Jeff...