This project has moved. For the latest updates, please go here.

Entity field Identifier

Jul 27, 2014 at 4:28 PM

I think the field Actor.Name and Films.Name a definitely different Fields.
In the db, both fields are identified as "name". In the Entity environment, this is not really clear.
The fields must be "actor/name" and "films/name" and then the fields are exact defined.

The second benefit is, that there are less db requests.

The following change makes this possible, Polaris works also with the new data.

I have not found to identify the store Version. The store version should be increased with this change.

        private static void AddMappingsForType(EntityMappingStore mappingStore, AssemblyMappingInfo assemblyMappingInfo, Type mappedType)


                    if (mappingStore.GetPropertyHint(p) == null)
                        // If there has been no mapping at all, then we create a property mapping
                        var propertyName = Char.ToLowerInvariant(p.Name[0]) + p.Name.Substring(1);

+                        //if (StorVersion > x) {
+                            propertyName = Char.ToLowerInvariant(entityTypeIdentifier[0]) + entityTypeIdentifier.Substring(1) + "/" + propertyName;
+                        //}

                        var propertyUri = assemblyMappingInfo.ResolveIdentifier(propertyName);

                            IsResource(p.PropertyType) ? 
                            new PropertyHint(PropertyMappingType.Arc, propertyUri) : 
                            new PropertyHint(PropertyMappingType.Property, propertyUri));
Jul 29, 2014 at 12:36 PM
Actually that is a deliberate design decision as it lets you share RDF properties amongst different classes, which is a common pattern. The [PropertyType] attribute is there to allow you to change the automatically assigned URI.
Jul 29, 2014 at 6:00 PM
Sure, in a RDF design for very dynamic data. But I think not in a EntityFramework, here the [PropertyType] attribute should be used for the same properties.
Jul 30, 2014 at 7:59 AM
The whole point of BrightstarDB is that we are trying to bridge the gap between static models and dynamic data. Not trying to do static models in RDF. Hence the design decision about this and about supporting multiple types and runtime type-coercion.
Jul 30, 2014 at 9:15 AM
Yes, this is exactly why I invest so much time in BrightstarDB.

The DB Models are static and the Customer perception is dynamic. Each customer solution brings more dynamic in the model, which can not really implemented in a static model. In best case, every class has it's own model.

A interface IActor can be used more times. Not the same interface, a interface with the same name and some different properties (copy). But the same properties can shared between different classes, this is the big benefit. This works also when the property is defined via interface/property.

Only an Idea, sure can I do a workaround.
In the meantime, I have almost passed the static mindset.