Doesn't seem to handle tables with data columns mapped to properties with different names

[kev160967]

So, for example, the database has TableOne with a non-nullable column ColumnOne, and that column is mapped to a property MyColumnOne in the entity. In the data loaded you set the property of MyColumnOne to some value. When the repository is initialised you will get an error telling you that ColumnOne cannot be NULL.

At a guess this would need an attribute containing the mapping details configuring, in the same way that non-matching table names need to be provided?

[christophano]

Could you provide an example that duplicates this issue at all?

[kev160967]

Hi Chris, I'll put together a small example that illustrates it - the system I came accross it on is rather large

[kev160967]

Example solution attached. Looks like the problem may be specific to ObjectContext. Initially put together a C# solution using dbContext, but couldn't reproduce the problem EffortExtraExampleVB.zip

[christophano]

Okay, I'm fairly certain I've got to the bottom of this. The problem is that the ColumnDescriptor that gets passed to the data loaders only has the Name and the Type. I can check for the presence of a ColumnAttribute, but that doesn't help when the name is changed using an EntityTypeConfiguration<> class or an edmx. The only way to solve this would be a pull request to the Effort library itself, asking for more information in the ColumnDescriptor object - I'll take a look at doing this.

[kev160967]

Thanks Chris. Does that tie in with problem not occurring with a DbContext based solution that also uses an EDMX file?

[christophano]

I'm not sure about that to be honest. It looks like it's going to be a lot of work in Effort to get this information out, so I'll contact the maintainers before I think about starting!

[kev160967]

Understood. I've attached the dbcontext example equivalent to the previous example, where it works okay, just for comparison EffortExtraExample.zip

Perhaps an option might be to pass a set of column mapping pairs in to the Table constructor, for any problem fields? Ie, rather than fight to get the metadata from Effort, get the user to supply it? If you think that might fit into your design, I might have a stab at it? Looks like we're stuck with ObjectContext for a while, so it would be worth the effort for us

Hmm, may be a non-starter, from a quick look. Will look properly when I get a chance

[uesleilima]

I'm experiencing this exact same problem here. I'm using ObjectDataLoader to populate my database with json objects (CSV files are ugly and not easy to edit) and, as my company policy to naming database objects is strict and non C# object-compatible, we use the entity framework fluent API to map the column names to the object properties. I was starting to have a headache wondering why it was not working, until I found this post.

Extra: Extension method to add json objects:

public static ObjectDataTable<T> Table<T>(this ObjectData data, string jsonPath, string tableName = null)
        {
            var dataTable = data.Table<T>(tableName);

            string json = File.ReadAllText(jsonPath);
            var dataObjects = JsonConvert.DeserializeObject<IEnumerable<T>>(json);
            foreach (T item in dataObjects)
            {
                dataTable.Add(item);
            }

            return dataTable;
}