search

christophano / Effort.Extra

Apache License 2.0
6 stars 3 forks source link

Nullable fields do not appear to be correctly initialized with Table Per Hierarchy #13

Open NameOfTheDragon opened 7 years ago

NameOfTheDragon commented 7 years ago

Hi. I'm having a problem with a table that uses Table Per Hierarchy to store a number of alternative items. Using TPH, the hierarchy pretty much MUST contain nullable fields as that is a prerequisite for TPH. However, my entities are not initializing correctly and all of the nullable fields are always initialized to null.

I have created a small reproduction of this problem (abstracted from an MVC web application) which you can find at: https://bitbucket.org/tigra-astronomy/effort.extra.ef6.tableperhierarchynullableint

When this code is run, it produces the following output:

Creating data loader with the following entities:
Id: 1, Title: fake observing session, Venue: nowhere, StartsAt: 01/01/2000 00:00:00, Description: description, ScheduleState: Scheduled, RemindOneWeekBefore: True, RemindOneDayBefore: True
Id: 1, Disposition: Pending, QueueName: Events, ProcessAfter: 31/12/1999 00:00:00, ObservingSessionId: 1
Id: 2, Disposition: Pending, QueueName: Events, ProcessAfter: 25/12/1999 00:00:00, ObservingSessionId: 1
Id: 99, Disposition: Pending, QueueName: Other, ProcessAfter: 17/06/2017 18:01:41, Label: This field is only present in OtherTypeOfQueuedItem

Observing sessions: 1
Reminders: 3
Reminders in database:
Id: 1, Disposition: Pending, QueueName: Events, ProcessAfter: 31/12/1999 00:00:00, ObservingSessionId:
Id: 2, Disposition: Pending, QueueName: Events, ProcessAfter: 25/12/1999 00:00:00, ObservingSessionId:
Id: 99, Disposition: Pending, QueueName: Other, ProcessAfter: 17/06/2017 18:01:41, Label:

Notice that the fields ObservingSessionId and Label are both null when read back from the database, but they both have values when creating the data loader.

christophano commented 7 years ago

Hey, sorry it's taken me so long to respond; this must be a record for me!

I suspect that this issue is due to those properties not existing on the base class, which is the only type the ObjectTableDataLoader<> actually knows about. I'm wondering if this can be solved at the same time as #12, as that will eventually result in the ObjectTableDataLoader<> knowing more about the actual table metadata too.

In the short term, if you created an object that matched the database table itself and added that instead then you could probably work around this issue for now.