Read-only Properties

[CodeMonkey]

Hi

Most of my tables follow a simple base design involving an ID (identity), Version (to keep OA happy), LastModifiedDate (to keep me happy - maintained by trigger), LastModifiedBy (To keep auditers happy - trigger managed).

I have managed to map and persist my simple objects but I'd like to know how I make some of my Properties readonly i.e. LastModifiedDate may be useful to view but I don't want the user (i.e. myself) to be able to edit it as it is managed by a trigger.

Regards

Shaun

[Damyan Bogoev]

Hello Shaun Wilde,

There are two possible approaches that you could use to achieve this. If you are using the latest version of Telerik OpenAccess ORM, you can use the Forward mapping wizard to do this. The second way is to do it manually.

Setting the field behavior using the wizards:
-    Select the project node which contains the specified class and run the Forward Mapping Wizard;
-    Locate and click on the field node. On the right you can select the Read-only option from the Field behavior dropdown;

Setting the field behavior manually:
This can be done by adding 

behavior="readonly"

to the class node:

<class name="class_name">
      <field name="name" behavior="readonly">
      </field>
</class>

inside the corresponding App.config file.   
Note that this would not work for primary key fields.

I hope that will help you. If any other questions arise please do not hesitate to contact us.

Sincerely yours,
Damyan Bogoev
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.

[CodeMonkey]

Hi

It took me a while to realise that when you said "latest" you meant the Beta code line not the main release line.

I used the forward mapping method you describe but my Property still has get/set which gives the impression of read/write. Is the class supposed to regenerate or is this expected behaviour?

You say this would not work for primary key fields, but surely where the identity is set by the database then this would be a perfect example of where it should be controlled to just read-only. Could explain why it will not work for primay fields.

Thanks

[Damyan Bogoev]

Hi CodeMonkey,

 Manipulating the field behavior results in changes in the configuration from which OpenAccess reads the model metadata( app.config). They are not reflected into the get and set property accessors as the fields are not really compiled as readonly, it is OpenAcess that takes care of this behavior in the runtime.

You can see the changes for the properties with different than readwrite (default) behavior inside the configuration file:
1.    Locate the field node inside the App.config file;
2.    Make sure the behavior attribute with the appropriate setting  is specified for this field;

One noteworthy thing regarding this topic is that in cases of readonly field behavior, on insert, field is set to null. That cannot be done on primary keys though.

Regards,
Damyan Bogoev
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.

[CodeMonkey]

How about if I manually edited the Telerik generated files so instead of

[Telerik.OpenAccess.Persistent(IdentityField="id")]
public partial class Asset
{
    private int id; // pk
}

// and

public partial class Asset
{
    //The 'no-args' constructor required by OpenAccess.
    public Asset()
    {
    }

    [Telerik.OpenAccess.FieldAlias("id")]
    public int Id
    {
        get { return id; }
        set { this.id = value; }
    }
}

I had

[Telerik.OpenAccess.Persistent(IdentityField="id")]
public partial class Asset
{
    private int id; // pk
}

// and

public partial class Asset
{
    //The 'no-args' constructor required by OpenAccess.
    public Asset()
    {
    }

    [Telerik.OpenAccess.FieldAlias("id")]
    public int Id
    {
        get { return id; }
    }
}

or alternatively if the FieldAlias attribute had to be on a property with get and set access.

[Telerik.OpenAccess.Persistent(IdentityField="id")]
public partial class Asset
{
    private int id; // pk
}

// and

public partial class Asset
{
    //The 'no-args' constructor required by OpenAccess.
    public Asset()
    {
    }

    [Telerik.OpenAccess.FieldAlias("id")]
    private int _Id
    {
        get { return id; }
        set { this.id = value; }
    }

    public int Id
    {
        get { return id; }
    }

}

[Thomas]

Hello CodeMonkey,

you can do this readonly properties in addition to the configuration file changes proposed earlier. The readonly properties are properties, but OpenAccess cares more about fields, and that is the reason why the configuration file entries are used to decide about the behavior. From our perspective, properties do not exist... That is also the reason why you need to have the alias attribute on them, so that they become proxies for the field that is named.

Kind regards,
Thomas
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.

[CodeMonkey]

So which of the 2 options should I take?

If I can control access via properties I see no reason to manipulate any configuration files as the access is restricted via the property.

[Zoran]

Hello CodeMonkey,

The two approaches differ in the level on which the restriction for write access is applied. If you go with the property get approach as you proposed, there is still the possibility for a write access on the field as it is still writable in an instance method of your Asset class. There you still have access to the private fields and are able to manipulate their values. OpenAccess though, gives you an additional level of protection which guaranties you that even if a field gets changed in an instance method, OpenAccess still does not allow for the new entry to reach the database.

All the best,
Zoran
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.