Artificial fields with custom attributes

[Erkka]

Hi,

Is it possible to have artificial fields created with custom attributes
in a way which does not require storing attribute information outside
normal OpenAccess definitions?

Thanks in advance!

Regards,

Erkka

[Zoran]

Hi Erkka,

 Could you give us some more clarification about what you are trying to achieve. How do you mean creating artificial fields with custom attributes? Do you mean creating fields tat have custom attributes which you can later access, or use some custom attributes for their creation?
What approach do you use at the moment? With the Q3 2010 release(from today) we have an alternative approach of defining artificial metadata using Fluent API.

Looking forward to get you feedback.

Sincerely yours,
Zoran
the Telerik team

[Erkka]

Hi Zoran,

Thank you for the response.

First I must say that I'm getting a bit confused how I should create artificial
fields and types in the first place. At first I tought best way would be use XML
as described in OpenAccess ORM Classic then I found artificialfieldstestwithmetadatacontainer
sample and now there is yet an another way to do this.

Could you please evaluating OpenAccess so I could decide wether it fits my needs.

What I would like to do is to create a data model that can be extended without recompiling.
I also need to have additional attributes on fields and types lets say for example RangeAttribute
on a Interger field. This however is not a absolute necessity as the same outcome can be achieved bit differently.
Then I would like to create a ASP.net Dynamic Data data model from OpenAccess
Model so I could use OpenAccess with Dynamic Data (unless Telerik has this implemented before)

With these requirements which approach should I take to my data model and artificial types and fields?
XML, MetaDataContainer or Fluent API?

Hope you can help me with my confusion.

Thanks in advance!

-Erkka

[Zoran]

Hello Erkka,

 I think I understand your scenario much better now and I think the OpenAccess is exactly the tool for you. 
Please let me shed some light on the situation and hopefully resolve your confuse:

• Extending a compiled class with artificial fields, does not allow custom attributes on those fields as they do not get actually compiled, thus the CLR is not processing them, but OpenAccess handles them specially using custom metadata. If you would like to put such attributes you will have to write your own logic for handling this kind of restrictions like the Range one.
• The approach of defining artificial metadata with XML was the one that we introduced together with the feature itself. However, about a year and a half from then, OpenAccess has considerably changed its API in the direction of easier usability for the customers. The Fluent API was introduced exactly for that purpose - writing intuitive .NET code that programmers are more used to instead of gluing strings in an XML format. 
• The OpenAccess runtime actually works with the XML configuration. If you work with the MetadataContainer as you have seen in my example - under the hood it gets translated to the XML definition you might be already familiar with. If you use Fluent API in the other hand - internally it gets translated to a MetadataContainer. So in the end whatever approach you chose it is all the same for the OpenAccess runtime.

Kind regards,
Zoran
the Telerik team

[Erkka]

Hi Zoran,

Thanks for the clarifications, much appreciated!

Is there any samples of using Fluent API creating artificial fields
and types that are known only at runtime?

If I would like to store artificial types and fields that were created during
runtime, is it possible to tap into the XML that was created under the 
hood and save it for later use? Or do I need to create my own logic 
for storing and creating artificial types and fields again in next application
startup?

Thanks in advance!

Regards,

Erkka

[Zoran]

Hello Erkka,

 There is not example that you could download and compile at the moment for this approach, however there is through documentation on creating artificial fields and types during runtime using Fluent API. You could find the referenced help articles here.

Regarding your second question, you should have your own logic for re-creating the artificial fields after application is restarted. You could save the artificial data into a database or serialize them in your own XML structure. However we will treat this as a nice idea and we could provide public API for serializing the MetadataContainer which is used during runtime so that it can be re-used later.

Regards,
Zoran
the Telerik team

[Bill Togkas]

Hi Guys,

Any update for this matter? Using version 2012.2.628 and have problems finding information about declaration of artificial fields.

[Zoran]

Hi Bill,

 The information about declaring artificial fields is available in our Fluent API documentation. However it is still not possible to add custom CLR attributes to artificial fields. Can you give us more information about how do you want to use artificial fields and what information do you require and is missing from your perspective?

Greetings,
Zoran
the Telerik team

[Bill Togkas]

Hi zoran

Its just seemed easier to store the XML at the database at a class definition table, load the first model that contains this table and then get the data to create the artificial model. Since the fluent Api can do all that i believe i will just change the artificial model to a fluent one and just feed the extra fields.

[Bill Togkas]

Hi guys.

I have the following scenario.

1) Have a FluentMetadataSource generated from the database.
2) This FluentMetadataSource contains a table that represents the artificial fields that will be loaded. (columns are => name , namespace,type etc)
3) I have a class that inherits from the generated EntitiesModelFluentMetadataSource (the generated metadatasource)
4) I can feed the inherited class with these artificial fields and create artificialTypes fields based on the values

the flow is
1) Create the model that will return the artificial fields -> OK
2) Create the model (same class) and add the artificial fields (seems ok)
3) Try getting the artificial  IPersistentTypeDescriptor --> Fails..

Facts:
1) If the artificial type is also declared at the initial model, this works (?? Ok how am i supposed to know which are the artificial fields if stored in the database)
2) The connection string is the same
3) the model class is the same...

PS: Great job guys, really love this :D

[Zoran]

Hello Bill,

 If you have two different models (even though they are conceptually the same, the second is just the first + artificial extensions) you should use different connection strings. Actually the connection string can be the same but is should be stored twice in the config file under different names. The reason for this is the fact that a model is cached with the connection string name serving as a key. So when you try to open the database using the extended model, you are still getting the behavior as if you were using the first model because of the cache. Try opening the database with a different connection string name passed to the context constructor and you should have no problems.

The other workaround is to call context.DisposeDatabase() that would destroy the cache and then the new context you create even with the same connection string should have the correct behavior.

Kind regards,
Zoran
the Telerik team

[Bill Togkas]

Great info Zoran, Thanks a lot !!

I Used the second way you suggested.
I just post this for tip. If you use the DisposeDatabase, make sure you have previously OpenAccessContextObject.CreateDetachedCopy of your artificial fields so they can be used after the Disposing!