I'm newbie in doctrine 2. i want to know which mapping required for doctrine 2?
I create my Annotation map with all columns, methods and etc.
I need to know it's required to define XML or YAML mapping for any kind of features in doctrine 2 and without them which feature i haven't?
http://docs.doctrine-project.org/projects/doctrine-orm/en/2.0.x/reference/basic-mapping.html
You only need to use one type of mapping and you've done so already with the annotation approach. This is also the preferred approach from what I gather.
The other mapping methods just let you work the way you prefer. So if you want to have your schema defined away from your model source code. You can use XML or YAML. A lot of the Symfony guys use YAML because it's what the framework is configured with. I personally prefer the annotation method.
Related
As a complete novice programmer I am trying to populate my neo4j DB with data from heterogeneous sources. For this I am trying to use the Neo4jClient C# API. The heterogeneity of my data comes from a custom, continuously evolving DSL/DSML/metamodel that defines the possible types of elements, i.e. models, thus creating classes for each type would not be ideal.
As I understand, my options are the following:
Have a predefined class for each type of element: This way I can easily serialize my objects that is if all properties are primitive types or arrays/lists.
Have a base class (with a Dictionary to hold properties) that I use as an interface between the models that I'm trying to serialize and neo4j. I've seen an example for this at Can Neo4j store a dictionary in a node?, but I don't understand how to use the converter (defined in the answer) to add a node. Also, I don't see how an int-based dictionary would allow me to store Key-Value pairs where the keys (that are strings) would translate to Property names in neo4j.
Generate a custom query dynamically, as seen at https://github.com/Readify/Neo4jClient/wiki/cypher#manual-queries-highly-discouraged. This is not recommended and possibly is not performant.
Ultimately, what I would like to achieve is to avoid the need to define a separate class for every type of element that I have, but still be able to add properties that are defined by types in my metamodel.
I would also be interested to somehow influencing the serializer to ignore non-compatible properties (similarly to XmlIgnore), so that I would not need to create a separate class for each class that has more than just primitive types.
Thanks,
J
There are 2 problems you're trying to solve - the first is how to program the C# part of this, the second is how to store the solution to the first problem.
At some point you'll need to access this data in your C# code - unless you're going fully dynamic you'll need to have some sort of class structure.
Taking your 3 options:
Please have a look at this question: neo4jclient heterogenous data return which I think covers this scenario.
In that answer, the converter does the work for you, you would create, delete etc as before, the converter just handles the IDictionary instance in that case. The IDictionary<int, string> in the answer is an example, you can use whatever you want, you could use IDictionary<string, string> if you wanted, in fact - in that example, all you'd need to do would be changing the IntString property to be an IDictionary<string,string> and it should just work.
Even if you went down the route of using custom queries (which you really shouldn't need to) you will still need to bring back objects as classes. Nothing changes, it just makes your life a lot harder.
In terms of XmlIgnore - have you tried JsonIgnore?
Alternatively - look at the custom converter and get the non-compatible properties into your DB.
I'm trying to explore the functionality of ServiceStack.OrmLite and can't understand if it possible to use bootstrap class for configuration (foreign keys, data types, column indexes, aliases etc.)? I don't wanna use data annotation attributes on my entity classes. Even usage of some sort of config's would be better than attributes. That is because i wanna have the chance to replace the ORM in future. Maybe exists third-party lib for fluent configuration?
There is no fluent mapping for ServiceStack.OrmLite. I share your reluctance to refer even the DataAnnotations assembly from my Model definitions. I like my POCO's clean as in entirely clean: separate in their own assembly, not referencing any 3rd party assemblies. It's not as much aesthetics as it's a ways of twisting my arm to avoid temptations to do short-hand stuff that breaks good design. I'm like - if it's not a clean ORM, it's just a tightly coupled DAL, and then it's all for nothing anyway.
Anyway - you can definately annotate your POCO classes in a bootstrapping/impl. kind of place - it's really quite obvious: use reflection and add the attribute at runtime, e.g.
typeof (User).GetProperty("Id")
.AddAttributes(new AutoIncrementAttribute());
Same principle of any attribute of OrmLite (and any attribute, really).
I found the hint in the Unit-tests for OrmLite, there's actually a Can_add_AutoIncrement_Id_at_runtime() unit test. Even though this is essentially unit-testing .NET core and not really OrmLite. Thanks, thourough tester-guy, anyway.
ServiceStack OrmLite creates schemas based on code-first POCOs. Adding attributes are a convenience to alter the sql generated table schema if you wanted OrmLite to create the tables for you. If you don't want to use attributes then manually create the SQL Schema in your database out-of-band, or after the tables are created remove the attributes.
Or use another ORM, OrmLite will never support mappings stored in runtime configuration files - which is against it's code-first philosophy.
I was going to implement a custom DisplayAttribute in order to allow dynamic display values based on model values, but I can't because DisplayAttribute is sealed.
Before I go off and write my own customer attribute that emulates the behavior of DisplayAttribute, can anybody think of why this is sealed? I'm assuming there is a reason behind it, and if so, that may be the same reason I shouldn't try to "hack" around this limitation by rolling my own.
I'm not asking anyone to read Microsoft's mind, I'm just hoping someone already knows the by-design reason it's sealed, so that I can take that into account when rolling (or avoiding) my own implementation.
In general it is considered best practice to seal attributes. FxCop has a rule about it, defined here. From that page:
The .NET Framework class library provides methods for retrieving custom attributes. By default, these methods search the attribute inheritance hierarchy; for example Attribute.GetCustomAttribute searches for the specified attribute type, or any attribute type that extends the specified attribute type. Sealing the attribute eliminates the search through the inheritance hierarchy, and can improve performance.
Many of the MVC attributes (ActionFilter, etc) are unsealed because they are specifically designed to be extended, but elements in the DataAnnotations namespace are not.
Not exactly what you asked, but following your intent...
You can still allow for dynamic display values, you just wont extend the DisplayAttribute.
Instead, you can implement your own IModelMetadataProvider which could contain any logic needed to create dynamic display values.
Brad Wilson, from the ASP.NET MVC team, has a good article and sample of this on his blog: http://bradwilson.typepad.com/blog/2010/01/why-you-dont-need-modelmetadataattributes.html
What is the use of AdditionalMetadata Attribute in MVC 3 . What is Use of that? Please provide me clear example how to specify and use it to render in browser.
Thanks!!!
It could be used to specify some custom properties that are not part of the standard metadata properties. Here's an article which illustrates an example.
Another option (and in my opinion a little bit cleaner, but it depends) is to use them through custom model metadata providers.
Here is one example of it.
Basically they are used for providing custom values from the model to the views, without requiring views to include logic to make these values up for themselves. Which results in a little bit cleaner and more generic views.
This is mostly of a design pattern question. I have one type of model that I'm going to get the data to create them from multiple sources. So for example one record my be created from an API where another is created via screen scraping with Nokogiri.
My issue lies in how best to abstract out these different data sources. Right now I'm building lib classes that return the same hash which I then use to set the attributes of the model. But I'm wondering if this isn't more of a case to use STI. Or if there is some other way of doing this I'm just not thinking about.
I think your design decision would depend largely on what attributes need to be stored. From your description, it sounds like you have a model with multiple data sources, but which would be storing the same attributes regardless of the source. In that case STI seems like overkill. When you retrieve a row from the table, does it matter whether the source is the API or the screen scraper? If not, then you could just define separate methods for each data source and use the appropriate method in the controller.
#instance = MyModel.new(:datasource=>"API")`
I'd say don't worry about inheritance (or mixing in code from modules) unless you really need to. There are some gotchas -- STI is not fully supported by some gems/plugins, for example.