Artificial fields with custom attributes

12 posts, 0 answers
  1. Erkka
    Erkka avatar
    7 posts
    Member since:
    Dec 2007

    Posted 05 Nov 2010 Link to this post

    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
  2. Zoran
    Admin
    Zoran avatar
    534 posts

    Posted 10 Nov 2010 Link to this post

    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
    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
  3. DevCraft banner
  4. Erkka
    Erkka avatar
    7 posts
    Member since:
    Dec 2007

    Posted 11 Nov 2010 Link to this post

    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
  5. Zoran
    Admin
    Zoran avatar
    534 posts

    Posted 11 Nov 2010 Link to this post

    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
    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
  6. Erkka
    Erkka avatar
    7 posts
    Member since:
    Dec 2007

    Posted 11 Nov 2010 Link to this post

    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
  7. Zoran
    Admin
    Zoran avatar
    534 posts

    Posted 15 Nov 2010 Link to this post

    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
    See What's New in Telerik OpenAccess ORM in Q3 2010!
    Monday, November 15, 11 am Eastern Time: Register here>>
    Monday, November 15, 10 pm Eastern Time: Register here>>
  8. Bill Togkas
    Bill Togkas avatar
    18 posts
    Member since:
    Mar 2010

    Posted 22 Jul 2012 Link to this post

    Hi Guys,

    Any update for this matter? Using version 2012.2.628 and have problems finding information about declaration of artificial fields.
  9. Zoran
    Admin
    Zoran avatar
    534 posts

    Posted 25 Jul 2012 Link to this post

    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
    OpenAccess ORM Q2'12 Now Available! Get your hands on all the new stuff.
  10. Bill Togkas
    Bill Togkas avatar
    18 posts
    Member since:
    Mar 2010

    Posted 26 Jul 2012 Link to this post

    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.
  11. Bill Togkas
    Bill Togkas avatar
    18 posts
    Member since:
    Mar 2010

    Posted 29 Jul 2012 Link to this post

    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
  12. Zoran
    Admin
    Zoran avatar
    534 posts

    Posted 31 Jul 2012 Link to this post

    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
    OpenAccess ORM Q2'12 Now Available! Get your hands on all the new stuff.
  13. Bill Togkas
    Bill Togkas avatar
    18 posts
    Member since:
    Mar 2010

    Posted 31 Jul 2012 Link to this post

    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!
Back to Top
DevCraft banner