Q1 2010 Backend Configuration Dialog - HigLow Key Generator

[Sörnt Poppe]

Hi there,

I just started using OpenAccess.

As far as I understand there is a old way to use OA (via the "Telerik->Open Access->Launch Open Access Wizzard) and a new one via adding a Open Access Domain Model item. Please correct me if I am wrong.

So I did the follwing:

• created a library
• add the Domain Model item and reverse mapped my FireBird 2.5 database
• created a console app and use the generated "OpenAccessContext" to access my Entities.

That worked, I am happy :-)

I now have now no idea how to generate new PK values for my FireBird table.
At the docs there is a HighLow settings mentioned that should be configured via the "OpenAccess > Configuration -> Backend Configuration Settings". But that menu item is disabled.

So my question is how to generate PK values?

Kind regards,
Sörnt

[Sörnt Poppe]

Another question:

Where do I define the Fetch Group within the new DSL Designer?

Kind regards,
Sörnt

[Sörnt Poppe]

Can someone please give me a hint to my issues?

Kind regards,
Sörnt

[Sergej Mertens]

Hi Sörnt,

if I remember right (currently I have no machine with the new version left), then it should be here:
Open the DSL designer. On the bottom of VS there is a new tab (don't know the name). Click an entity and edit settings in this dialog. There are Options for Keys, Field-Mappings and fetch groups.

Greetings,
Daniel

[Zoran]

Hello Sörnt Poppe,

There are several approaches towards the solution of your problem. First thing i should say is that the HIGHLOW key generator is mostly used as an option in forward mapping. There OpenAccess extends your schema with an additional table that is used for calculating the keys of the tables that use such generator mechanism.

The Firebird users are often using a Generator and a Trigger to generate the unique auto-increment primary key values for their tables. As a Firebird user I suppose you are familiar with this approach, so here are the steps for you to take advantage of this in an OpenAccess model:

• You should map your tables in the designer, as you have already done. The designer though is not aware of the triggers in your schema so we do not automatically detect the auto-incremented primary key field from your database table.
• Using attribute mapping, you should have generated something like this for your primary key column(assuming your table is named "Categories" and you Primary Key column, "CategoryID"):

         

[Table("Categories")]
    public partial class Category
    {
        private int categoryID;

        [Column("CategoryID", OpenAccessType = OpenAccessType.Int32,  IsPrimaryKey = true, SqlType = "int")]
        [Storage("categoryID")]
        public virtual int CategoryID
.....
    }

• You should manually set the BackendCalculated property to true on the Column attribute. This setting tells OpenAccess that the value of a given property is calculated on the database server. 

        [Table("Categories")]
    public partial class Category
    {
        private int categoryID;

        [Column("CategoryID", OpenAccessType = OpenAccessType.Int32, IsBackendCalculated = true, IsPrimaryKey = true, SqlType = "int")]
        [Storage("categoryID")]
        public virtual int CategoryID
        {
.....
     }

For the future versions of the new designer, we will add interactive options for using the HIGHLOW key generator for generating identity values for some entities. Adjusting and customizing the generator for the different entities will be available too.

Sincerely yours,
Zoran
the Telerik team

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.

[Sörnt Poppe]

Thank you very much!

I didn't test it right now, but when will that class be recreated?
Each and everytime I do edit some settings within the DSL Designer? If so, will the manuell added attributes be overriden?

Kind regards,
Sörnt

[Zoran]

Hi Sörnt Poppe,

Unfortunately, the behavior is that if you re-generate the classes within the designer, the manually added code will no longer be there. This will be solved in the next version where we will add options for the missing settings within the designer so you will be able to set them from there and generate them automatically.

Best wishes,
Zoran
the Telerik team

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.

[Sörnt Poppe]

Thank you for the answer!

It looks like that the new designer is right now not usable for me.
Can please give me a date range when this issue will be fixed. When your are talking about the next version I guess you refer to Q2 2010 - right? I need that to comunicate to my boss and switch to another ORM mapper

I am a new Telerik user and a bit disapointed about the state of the OpenAcces product.

Some thing I missed right now:
support for
* IEditableObject
* INotifyPropertyChanged
* IDataError
* RIA Services

* No concept of Interceptors

What me confused at most is the fact that there are two differen API's (pre DSL designer and the DSL designer),
"OpenAccessContext" the "old" Sope behaviour. Where are the differences? Why is/will the old behaviour droped?
What I also miss is a comparison between EF and OpenAccess.

Kind regards,
Sörnt

[Sörnt Poppe]

I guess the support for the missing interfaces can be "waved" in via APO - PostSharp comes to mind.
Will there be any problems using PostSharp (post compiler) with OpenAccess.

Kind regards,
Sörnt

[Sergej Mertens]

Hi Sörnt Poppe,

I have tried waving aspects in on OpenAccess enhanced assemblies but couldn't get it to work. As there are some sources on the net which stated that this work, I hadn't any luck. The PostSharp compiler thowed some errors. OpenAccess uses his own AOP-enhancer called VEnhance.

Especially for the interfaces INotifyPropertyChanged and IDataError I comcluded that it's much better to have control over these interfaces than stupidly waving it in. I created complex business objects with dependant properties which needed to implement these interfaces with care. My approach was to create a base class with basic mechanisms for these interfaces and inherit each business object and using these Methods (like OnChanged, etc. and a complex dependency manager for calculated properties). This can be done easy, as in reversemapping scenarios each generated class is a partial class and can be extended in an own code file. For forward mypping it's much simpler, because you write the business objects by yourself.

One approach I haven't checked for now is to use T4-templates for basic code generation of "simple" DTO's.

Support for RIA services is in Telerik's pipeline for the Data Service Wizard (currently available as beta). Please use forum search for a statement from Telerik concerning this.

Greetings,
Daniel

[Dimitar Kapitanov]

Hello Guys,
Let me again shed some light on the questions asked:

We have few things in development that will allow some, if not any of the requested features (at least implementing them in a correct way, some of them are dependable on runtime features that are not there at the moment):
 + Double Derivation: this is a special code generation technique that derives a 'base class' and a inheritor (your actual class), and marks all base properties as virtual. That way guys you will be able to override the generated code form OA in the following manner:

MyProperty
{
 get
 {
   return myPropertyValue;
 }
 set
 {
   this.OnNotifyPropertyChanging();
   base.MyProperty;
   this.OnNotifyPropertyChanged();
 }
}

...so you can augment the generation the way you want, where required.

+ Automation for: System.ComponentModel.DataAnnotations attributes, INotifyPropertyChanged/INotifyPropertyChanging. What automation means is that we will provide wizards and other infrastructure so that you can setup those for yourselv through the designer.

+ Ria /ADS support - we know this is very important and we are hectically working on that. I hope we will have descent support in the DevConnections event timeframe (~ one month)

+ VS 2010 support (~ one month)


Please provide me with more information on 'No concept of Interceptors' that you mentioned earlier. If you refer to the ADS interceptors, we will have them in the Ria/ADS time-frame already mentioned, If you refer to something else, please explain.

Regarding the comparison document EF/OpenAccess ORM, I guess we should provide that when we see the final bits of EF 4.0?


Best wishes,
Dimitar Kapitanov
the Telerik team

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.

[Sörnt Poppe]

Hi Daniel,
Hi Dimitar,

thank you for your answers!

@Daniel,
Maybe I want to much for a domain model. I want to eliminate stupid repeating code that is needed for the most properties.
I agree that weaving is somtimes not what you want (to stupid) but at least defining Aspects at Property level will be helpfull.
But I gess that is not support by the DSL designer.

In my ideal world:
I want the DSL designer to quickly setup my Domains and keep them maintainable in a visual way. I simple don't want to create a bunch of classes and do the mapping manually I have to solve my bussinis logic and not stupid mapping and infrastructure stuff.

Right now the Designer looks for me like a "one time" usage, namely to create the model for the very first time. Than I have to adjust the attributes and never ever touch the Designer again because it overrides my settings.

@Dimitar
we uses at your current project NHibernate. NHibernate has the concept of Interceptors. We created one and them for expample to set the "CreateAt" "CreatedBy" "ModifiedAt" "ModifiedBy" fields. We also used them to implement some bussines logic.

You also mentioned some time frames ~ 1 month.

To get something we all can count at: Please update the Roadmap at the pinned post.

Kind regards,
Sörnt

[Dimitar Kapitanov]

Hi Sörnt Poppe,
I will evaluate the interceptor concept in personal, and see whether we can allocate development to such a feature in the Q2 time-slot. But definitely it looks interesting.

We will update the roadmap properly as well.

Sincerely yours,
Dimitar Kapitanov
the Telerik team

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.