Upgrade guidance to 2010.2

[Ben Bolton]

We would like to consider upgrading to the latest version of ORM and leverage a domain model which (as I understand it) will allow us to get "delta sql scripts" that we can polish up for delivery to our customer(s) without destroying their existing data.

But... Your documentation states:

If the project is enhanced with previous version of Telerik OpenAccess ORM, do not add the new designer files to this project. Use the new OpenAccess Visual Designer for new projects.

• What does this mean?
  
• Can we convert to the 2010.2 version of ORM and is there any guidelines for doing so.
• Can we convert the forward mapping to a project that includes the features of the domain model.  (it is my understanding you have a tool to do this for the reverse mapped classes.)  Are there any guidelines for doing so?

Background:

We have a large solution which uses Telerik ORM 2009.3  for about a dozen persistent objects.  Most are quite simple, but 1 includes a base object, a derived object, and a referenced object.  Most of the objects were forward mapped and we allowed Telerik to create the DB tables.   A few of the objects were reversed mapped.

In addition we have another dozen objects which use a proprietary .NET framework to create the DAL.  We left it in place because it was working and fairly isolated from the rest of the solution.

We did not configure Telerik to use stored procedures.

We've delivered the solution to a customer who is successfully using the application.

We have new requirements which include:

1) no dynamic SQL, everything must be in stored procedures.
2) additional fields need to be added to a few of the persisted classes and a couple of existing fields need to be expanded. 
3) The stable proprietary DAL needs some modifications and we would like to convert it over to ORM

We've done some preliminary testing and believe we can migrate existing ORM classes to use stored procedures quite easily.

We are concerned that modifying the fields with our current version will delete and rebuild the database tables. While that is marginally acceptable for development, it is unacceptable for existing customer(s).



Ben

[Petko_I]

Hi Ben Bolton,

Let's discuss the topics in the order you mentioned them.

In fact we have not changed the code for generating DDL scripts. There isn't a new feature regarding the content of the scripts. What we provide now is an improved user interface in the form of the Update Schema Wizard.

You cannot mix the visual designer with the old scope approach. A project that has been previously enabled by OpenAccess cannot contain anything related to the visual designer. One of the two approaches is chosen and from then on the choice is maintained.

You can upgrade your project’s references to the Telerik OpenAccess assemblies and this is all that needs to be done to start using our new version. To upgrade an already enabled project, right-click it in the solution explorer and choose OpenAccess -> Update Config References from the context menu. If you wonder where the old menu items are have a look at this blog post.

We are aware that introducing major changes to our product requires taking into consideration the numerous projects already built with the classic wizards. That is why we have included an upgrade tool to easily convert your reversed engineered scope model to a domain one. The blog post here describes in details what needs to be done in order to execute the conversion smoothly.  However, in the current version of OpenAccess we do not have an automatic conversion for a forward mapping scenario. We plan to introduce such a tool for Q3. Unfortunately, the tedious work of manually creating all the entities from scratch is the only option now. You can also try reverse engineering the existing database with the old wizards to see how the persistent classes will be generated - check if there is some specific naming applied to your model. Once you have the right content of the reversemapping.config you can proceed with the Upgrade Model Tool. Yet, I suspect that there might be some discrepancies.

You can specify stored procedures for CUD operations both with the classic wizards approach and the visual designer - have a look at the following help article. Executing stored procedures is also easily achieved with the scope - see Using GetSqlQuery to execute stored procedures for reference.

Adding new fields to the model is just as easy as writing them in the persistent class definition, marking the properties with the FieldAlias attribute and rebuilding the project (assuming that the Update Database property is set to true). Null values will be inserted for the new columns of the existing records. Expanding the column type from a varchar(255) to a varchar(512) in the forward mapping wizard for example will only alter the definition of the existing column. When the fields and properties are renamed we recreate the underlying columns and in this case only losses take place. I suggest you  experiment with the type of changes you want to make with the wizard before altering straight away the existing database.

Best wishes,

Petko_I
the Telerik team