Alex (Xtensive) wrote:

Sorry for such a "thinking" - there is no simple answer (esp. second part), so I stuck on this for 2 days.

Let's start from the first part. The options I see:

1) Do this relying on DO4 schema upgrade layer. I won't recommend using this option here, since this layer is designed for minor schema changes, but not major. E.g. each rename requires an additional hint. If there must be import-export, you'll need two types ("old" marked as [Recycled] + "new"), or even two hierarchies of types. Moreover, currently there are some lacks related to inheritance changes - there are no hints for that. So e.g. moving a type closer to the root is complex case. Such complex changes must be handled via import-export or direct SQL in upgrade handlers.

Since in your case this is an initial import, there might be a lot of changes to describe, so I'd recommend you to use a different option.

2) Do this replying on DO4 for transform & load + DO39 for extraction. Since v3.9 requires .NET 2.0, it will be impossible to use both versions in the same AppDomain, although transferring the data via WCF isn't a big problem - especially if something unified is used on DO4 end. "Dynamic" keyword might be quite helpful here: I'd convert DO39 objects to unified wrappers compilable both in .NET 4 and .NET 2, and pass them through WCF channel.

A bit complex, but safe, because it relies on frameworks @ both ends.

3) Do this using DO4 and LINQ to SQL in the same AppDomain. We already use this option to consume third-party databases to DO4 DB, and actually it seems it is the best one. LINQ to SQL is enough flexible from the point of mappings; moreover, it's easy to generate classes from DB structure, that is really nice in such cases.

AFAIK, we import ~ 100-table database using this approach in one of projects we currently run; total count of tables managed by @ DO4 domain exceeds 400. Taking into account 5-person team has spent just 4 months on this (the most complex part there is UI), I think the result is simply excellent.

Issues:

• L2S designer is really slow on large models (100+ types).

4) Do this using purely SQL-based ETL tool. Might be a good option as well - especially if inheritance-related changes absent there.

Alex (Xtensive) wrote:

Answer to the second part - WinForms support:

> What do we need to do to have proper WinForms support with DO4?

We don't support any of WF interfaces, e.g. IBindingList and IEditableObject aren't supported. But there is no WF support without them.

Likely, it won't be too complex to implement both of them - as far as I can judge, we have all the necessary infrastructure.

> Do you guys plan on building these things any time soon?

We should analyze demand on this; there is a big chance we'll need this as well, but I'll know this more precisely only in June.

I'd prefer to avoid spending the time on this during May-June; but if this is really important for you and few more people, I can easily change the opinion.

I hope to finish with v4.3 on this week. And, as usual, I'm going to poll the customers about next set of features. So I'll include this one to poll.

> If not, would it be feasible if we built this ourselves (then maybe even published it for other DO customers to use)?

That's surely ok, although it's better if we'll take care about this. On the other hand, if this won't be possible, we're ready to help you with the implementation - this implies we'll provide you access to v4.3 codebase, explain possible approaches, review the code, etc.

> Any guidance you can provide on what would be the best approach for this?

Currently I can't provide an exact description of the best approach here, but I see at least two options:

• Rely on DisconnectedState savepoints to implement IEditableObject methods. Issue I see is that IEditableObject event order isn't well-aligned with global savepoints or nested transactions: there can be sequences like o1.BeginEdit, o2.BeginEdit, o1.EndEdit, o2.CancelEdit. So:

• We can rely on temporary store ensuring objects return temporary values inside BeginEdit regions. Such a store can be implemented e.g. as a dictionary inside Session extensions.

• Another alternative is to implement a store for original values using the same approach. Probably, this is the most attractive option.

I think we need to evaluate some of these options to make final decision. + I should talk with team members that remember how these WF interfaces work a bit better ;)

There should be some issues with validation, etc., but in general I don't see any serious obstacles here.

Tony wrote:

3) Do this using DO4 and LINQ to SQL in the same AppDomain.

Does this mean I could use a 'LING to SQL' mapping to my Do V3.9 database to combine with queries on my DO4 database using the local collections as described in http://blog.alexyakunin.com/2009/09/uncoming-changes-local-collections.html

Alex (Xtensive) wrote:

If local collections will be used @ DO4 side, this will work.

LINQ to SQL also provides some support for this, although I don't remember the limitations there (e.g. do they use temporary tables when necessary, do they support only collections of primitive types or not, and so on).