Simplify the data access plumbing in desktop and Web applications. Telerik OpenAccess ORM comes with both forward and reverse mapping support and the tool offers transparent persistence for your DAL and business objects. Telerik OpenAccess ORM provides tight Visual Studio integration and allows you to create database independent code seamlessly. You will find many advanced features for code optimization and caching, as well as customization freedom to generate the code you want.

What's new in RadControls for OpenAccess ORM Q1 2010?

·         New Visual Designer - The designer gives developers the ability to map their databases on a specially designed graphical surface as well as perform modifications to the mapping process and the domain model.

·         Added Support for VistaDB – support for the embedded SQL database engine has been added.

·         LINQ Support Enhancements – support for the SelectMany operation has been added.

Some of the features included in the designer are:

·         The DSL Designer: a specialized visual editor that visualizes the mapped classes and their relationships. You can interact with them with simple point-and-click. The designer offers a contextual menu for the most used operations; zoom in/out functionality, export to image, etc.

·         Mapping Details Editor: specify the class and association mappings required for the runtime. The tool can configure class inheritance and stored procedures for CUD operations for the classes updates.

·         Schema Explorer: shows the relational layer from the database in a hierarchical order; specify which elements should be mapped to or removed from the conceptual part of the domain model; allows for drag and drop mapping.

·         ‘Update From Database Model’ Wizard: shows the difference between the database content and the relational layer of the actual model in terms of what is still missing, should be removed or modified in the model. From there you can insert unmapped tables, views or stored procedures into your domain model. It uses an unique approach that can show all the details (differences, etc) in the compared models.

·         Entity Diagram Explorer: shows the conceptual layer of the model, or the classes that will be generated. It contains the same information that is in the designer but in a hierarchical order. Modifications of their basic properties and operations are allowed through the standard properties window.

·         Model Settings Dialog: allows for fine tuning the behavior of your domain model by allowing you to specify naming, code generation, caching and concurrency control settings.

·         Toolbox Items: allow you to perform the basic drag and drop mapping, set table relationships and inheritance as well as insert comment.

·         Validation Rules: help validate your model once you are finished working with it and eliminate mistakes like missing primary keys.

·         Data Services Wizard: The wizard is no longer a separate installation but is fully integrated in Telerik OpenAccess ORM Q1 2010.

·         Metadata API - OpenAccess provides an API to access all metadata information during runtime. This contains the complete database schema definition used. The entry point is at the database instance, you can reach it from the ObjectScope via scope.DataBase.MetaData. To find specific class/table/field/column information you can use Linq.

·         Database level cache API - The OpenAccess database level (or second level) cache needs an API to check the cache content and to evict part of the cache. The API is available at the database instance and can be reached from the ObjectScope via scope.Database.Cache.

·         Configuration support for SNAPSHOT transaction isolation - You can now specify SNAPSHOT in the backend configuration for systems where this is supported (e.g. MSSQL). Shared columns support - A column with a foreign key constraint in the database can be mapped to a simple type field like an integer but it can additionally be mapped to a reference type field like Person.Address. The data in the database is in this case always an integer. The ORM automatically translates the integer to a reference and vice versa. Therefore it is possible to map a single column in the database to two fields in the object model. One of the fields must be of simple type and needs to be of reference type.

·         Performance enhancements for read access - Reading data is complex because lots of metadata and mapping related code has to be executed. The reduction of layers and memory consumption makes the read access faster.

·         SQL Server Compact 3.5 Desktop Edition - OpenAccess can now work with the SQL Server Compact Edition on desktop and server operating systems. Because of the backend limitations inSQL statements like subselects and stored procedures not all OpenAccess functionality is supported.

·         SQL Azure - OpenAccess can now work with the Sql Azure database. The database can be accessed from your local computer or from another machine in the cloud. All OpenAccess functionality including full design time support is provided.

·         .NET connection string support - The definition of the database connection was OpenAccess specific. Now a normal .NET connection string can be used too. The enable project wizard can use and test those strings as well.

·         Full artificial support - After having artificial fields support OpenAccess comes now with artificial types support. This also means that types can be defined on the fly and the database schema can be updated. The access to the artificial types is similar to the artificial fields.

·         API to check and update the database schema - In the development process new versions of the customers product will be shipped. These new versions might contain schema updates as well. OpenAccess offers an API to do this schema changes just before opening the database with a new version. Nevertheless this cannot be an automatic process because schema analysis takes time and schema migration with data migration might be a very long running process.

·         Auto setting for ObjectScope cache - OpenAccess sometimes had problems keeping references to the data in a fetchplan. This might result in GC runs throwing out the fetched data before the application can access it. The auto reference type setting makes sure that this cannot happen. This is the new default.

·         MySql supports System.Transactions integration - OpenAccess uses the MySql 6.04 driver now. This supports integration into System.Transaction. OpenAccess is able now to use MySql Transaction with it's System.Transactions integration.

·         Use ObjectContainer to copy data between different databases - The object container got a new method to mark all data inside the container as new. This can be used to insert the data into a fresh database. The API is ObjectContainer.MarkContentAsNew()

·         IsDirty(FieldName) missing - Sometimes it is necessary to check if a specific field is dirty. The API was missing and is now added. Breaking change: The enhancer contract has been changed. All enhanced assemblies must be recompiled.

·         Relax the need to call scope.Dispose() - In the past, a call to IObjectScope.Dispose() was required to release the resources of an object scope. The code has been altered so that the GC is better able to collect unused object scopes, relaxing the need to explicitly call Dispose(); it's still a good practice, however.

·         LINQ: Support for Math.Min/Max etc - Allows the usage of System.Math functions Abs/Min/Max/Acos/Asin/Atan/Cos/Sin/Tan/Sqrt/Sign/Cosh/Sinh/Tanh/Atan2/Floor/Ceiling/Truncate/Exp/Log10/Log/Round(a,b)/Pow. The methods will be pushed to the server and so that calculations are possible. Be aware, that different database backends calculate sometimes different values (e.g. Round on MSSQL and Oracle).

·         LINQ: OrderBy clauses not working for calculated expressions - The query 'from p in OrderDetailsExtent orderby p.Number * p.Weight select p' was not working.

·         LINQ: Allow ordering based on methods over columns - Allows the use of some methods like string.ToLower() / string.ToUpper() as an expression for the ordering, e.g. "order by x.Name.ToLower()" .

·         LINQ: Changing ForwardsOnly, ParallelFetch, IgnoreUncommited, Debug and BackendQuery from properties to methods - The API for OpenAccess LINQ has been changed: The BackendQuery property value is now obtainable from the generates IQueryable instance with the ToString() method.

·          LINQ: Move ExtensionMethod Extent() to Telerik.OpenAccess namespace - The extension method Extent() that is the main entry point for creating LINQ queries has been moved out of the Telerik.OpenAccess.Query namespace to the Telerik.OpenAccess namespace so that less namespace using statements are required. This possibly requires customer code changes in cases where only Telerik.OpenAccess.Query was imported; such a file must now only include Telerik.OpenAccess. LINQ: Support for boolean projections - Support for 'where ... select x = y' LINQ statements.

·         LINQ: OrderBy on identity was not working - The query 'from x in PersonExtent orderby x select x' was not working.

·         LINQ: Improve support for non-direct projections - Projecting into a given class

·         Upgrade functionality for enabled projects - The Check Settings wizard should be able to find and fix any discrepancies between the installed version of Telerik OpenAccess ORM and the version used to create the project. This includes all aspects like assembly references, project settings, resources, enhancement and postbuild steps.

·         Reverse mapping should support stored procedures with OUTPUT parameters - Static method to call stored procedures with OUTPUT parameters should retrieve the output parameter values and pass them out via 'out' parameters

·         ora_rowscn pseudo column support for version control - ora_rowscn is a pseudo column in each table in Oracle 10 and above that reports a unique version number for a row. Pseudo columns can be used as backend side version mechanism. The problem was, that OpenAccess delimited the pseudo column together with all other columns. You have to add a long field to your persistent class in order to use this column. Use that for concurrency control with type=backend.  Oracle: Improved reading of NUMBER columns that are mapped to System.Double or System.Single - When a System.Single or System.Double field is mapped for Oracle, the resulting FLOAT (63/126) column can hold values that are bigger than what a System.Decimal can represent. The change affects the way such columns are read as now values exceeding 28 digits can be handled correctly, no longer resulting in exceptions.

·         ObjectContainer performs closure analyzation before serializing - When an ObjectContainer is serialized, it performs a closure traversal before in order to really collect all instances that need to be serialized.

·         ObjectContainer ChangeSet should be version agnostic with regard to OpenAccess API assembly - The serialized Object Container cannot be deserialized if the OpenAccess version has been changed in the meantime.

·         Allow ObjectContainer.Apply() when a transaction on the object container is active - The purpose is to allow modified object containers to fully use the resolve proxy event handler. Otherwise only clean containers can programmatically lazy load instances. ObjectContainer.Apply got a new overload with an additional bool 'force' parameter.

·         Improve handling of ntext database types with ntds driver - NTEXT in sql2000 and OpenAccess produced an exceptions when try to operate with it. Changing to varchar was working.

·         Reverse mapping does not recognize autoinc fields in MySql db tables - When reverse mapping a MySql database, AUTOINC fields are not recognized properly. So IDs of newly inserted objects are not being refreshed after scope.Transaction.Commit(). The reverse mapping wizard has a checkbox now where you can specify per column that it contains a server side calculated value.

·         Two projects with the same name in a solution prevents OpenAccess from loading - If a solution contains 2 different projects with the same name OpenAccess addin crashes. It happens because project short names are used in a dictionary instead of unique names. Workaround: Rename one of the projects.

·         Enhancer cannot enhance Linq new types in select - A query like: var result = from o in os.Extent<LINQEntities.Person>() where true select new { o.Age, o.Birthday }; will not be enhanced in the right way.

·         Targets in the Target view in the Check Settings wizard should be sorted alphabetically - In the targets tree view of the Check Settings dialog the classes are also not in alphabetical order. This is non-practical if you have a lot of targets and every time you open the dialog the target you are looking for appears at a different position.

Telerik OpenAccess ORM features

Forward and Reverse Mapping

·         Forward Mapping - OpenAccess allows you to start working from scratch with your object model and just creates your new relational database with an optimized data schema. You don’t need to think in relations anymore, but you still can. OpenAccess optionally allows you to define almost any kind of schema and you can influence the given names of tables or columns.

·         Reverse Mapping - OpenAccess additionally allows you to start with your legacy database. The reverse mapping experience begins the minute you connect your new Visual Studio project to the legacy database using the Reverse Mapping wizard. OpenAccess recognizes the data model, data types and additional information like keys and creates the matching object model. Then you can start designing and developing your new .NET application. 

·         Roundtrip Mapping - You can even change directions: any change in the object model will change optionally your schema and any change in the database can optionally change your object model.

·         Dependent instances - You can attribute a relationship so that the dependent instance is automatically deleted when no reference to it exists any longer.

Support for 6 Databases - Enjoy database independence with full support for the most popular databases:

·         Microsoft SQL Server

·         Oracle

·         MySQL

·         Firebird

·         Sybase SQL Anywhere

·         Advantage Database Server

Deployment Flexibility, Mapping in the Middle

OpenAccess supports modifications of the database only within the scope of an active transaction. This addresses the real-world challenges of durability, consistency, atomicity and isolation. Therefore OpenAccess does not allow nor support any risks which might come from the underlying database. That’s why we support only fully transactional databases, focused on the most used databases for .NET applications. If you miss one important to you, please let us know.

OpenAccess defines a mapping in the middle: all mapping information is per default stored in the app.config file, so outside of your C#/VB code and outside of your database. This allows you not only to deploy your application with one object model and different database schemas for different deployments, it also allows to map differently for different database vendors. No need of any change in your code. Even if you don’t need this flexibility initially, it keeps your code independent. And it might even help to migrate your existing apps and databases to other, new databases (reverse map your old database/vendor and forward map it to your new ones).

Support for LINQ, OQL, and SQL Languages - With OpenAccess you got no limits, you can just use the best of all words, even combined.

·         LINQ - OpenAccess supports LINQ. The major advantage of LINQ besides of its object-orientation is the compile time check of your queries - no surprises later during runtime.

·         OQL - OpenAccess additionally support OQL, also an object-oriented query languages defined a long time ago by the Object Database Management Group. At first, it was there before the invention of LINQ and but now you can use it in such cases where you need to build the query at runtime dynamically.

·         SQL - If you got any special to do or want to re-use some existing SQL statements, you can do it. Just use SQL and bypass OpenAccess.  To execute a query life on the database, you don’t need to write a line of code: Use the OQL browser from within your Visual Studio.

Transparent Data Access, Lazy Loading and Automatic Change Tracking

OpenAccess uses lazy loading where your application objects are filled with the data upon access. Not all fields will be filled immediately, so collection or picture fields can be deferred in their population. This has the advantage of saving memory and network bandwidth while preserving easy access – when the field’s content is needed, the data is fetched transparently from the database server. Of course, you can decide which fields are to be fetched when, and OpenAccess provides sensible defaults.

Modifications to values of the persistent fields are automatically tracked. You don’t need to notify the OpenAccess runtime system that an instance is to be written. When modifications are detected, only the necessary columns are included in the resulting SQL statements. All referenced persistent objects will be handled as well, and only complete object graphs are stored – no instance is left behind.

Visual Studio Integration - OpenAccess ORM is tightly integrated into Visual Studio, so you don’t need to change your environment nor the way you develop. It comes with various wizards to make your life easier and to visualize what you do. OpenAccess supports IntelliSense and the documentation is integrated in the Visual Studio Help system. OpenAccess works with Visual Studio 2005 and 2008, on .NET 2.0, 3.0 and 3.5, and supports both C# and VB.NET.

Disconnected API

OpenAccess unique ObjectContainer API concept has been the first ORM feature supporting disconnected data scenarios. Whether you’re thinking of mobile devices, web applications or replications - you need disconnected data management you can count on. To work with portions of your data in a disconnected mode, just take them with you. OpenAccess keeps them transactionally save and uses little network bandwidth by only exchanging the minimum change set. So it tracks which objects have been changed or are new. 

The offline ObjectContainer API shares a common interface with the online ObjectScope API, and parts of the applications can be implemented independent of their connectivity. 

The ObjectContainer serves as a bag which can hold object network, provides serialization, change tracking and the ability to apply changes in a round-trip fashion to the database.

Synchronized Distributed Level 2 Cache

OpenAccess provides a cache which can be shared by many database access instances (object scopes) in process. This is useful in situations where a lot of data is shared and commonly asked for. A typical example is a web server where much of the data is stable, sharable and commonly used.

Entries are evicted from the cache, when objects change. The cache is populated upon read access, configurable in its sizes and stored entry types and uses LRU overflow handling.

Entries in the cache are object states (representing the data of a single object) and whole query results. That means, the result of recurring queries can be stored in the cache and such queries will not hit the database server unless the cache entry is evicted. Eviction is automatic but can also be triggered manually.

Not only is such a cache shared within one process, but many of those caches can easily be coupled over the network to provide a distributed synchronized cache. The key benefit is that the Level 2 Cache can be used even in such scenarios where multiple application or web servers are put together into a farm.

The network access for such a distributed shared cache is optimized by using a asynchronous reliable multicast protocol. This is perfect for a cache cluster of unknown size.

Boosting Performance by using Fetch Plans - OpenAccess ORM provides for declarative coupling of Object Model and Activities through Fetch Plans.

FetchPlans describe object networks for performance optimizations. 

With the up-front declaration of a FetchPlan, OpenAccess is able to know in advance which object graph will be used by your code. This greatly improves your application performance in an easy and declarative manner.

This feature combines very well with the data fetches done by your application and avoids a common performance pitfall that is known as the ‘N+1 query problem’. Instead of querying for 1 order and then performing the n order details, a FetchPlan can be used to issue one optimal query fetching both order and its details. 

The FetchPlan is built up during runtime by a simple yet powerful API. The basic intention is to have a FetchPlan per use case. There is always a current FetchPlan, and this FetchPlan is used by queries and object navigation too. 

Philosophically, FetchPlans are the countermeasure to lazy-loading as they provide information for eager-loading.

Flexible Concurrency Mechanisms

OpenAccess supports both optimistic and pessimistic concurrency control. Both approaches can be mixed during runtime. Additionally it is possible to automatically obtain a pessimistic lock upon the first modifying access in an otherwise optimistic transaction.

When using optimistic concurrency control (the default), conflicts can be detected by designated version fields, the old content of the modified fields or all fields. And you can also turn conflict detection off.