Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I am a little confused based on your description, but will try to answer the scenarios I think you might mean:</p> <p><strong>Option 1</strong>: I think this is what you are after: You are creating objects of the parent class. Later, you have more information and want to 'downcast' them to the appropriate subclass. This is not possible in this way with EF. Once the object is created as a specific type that is what it must remain. The option then in your case is the following:</p> <ol> <li>Does this object already exist as (parentType)</li> <li>Delete Object(ParentType)</li> <li>Save object (ChildType)</li> </ol> <p>See better worded explainations than I could give here:</p> <p><a href="https://stackoverflow.com/questions/2618586/add-child-to-existing-parent-record-in-entity-framework">Add child to existing parent record in entity framework</a></p> <p><a href="https://stackoverflow.com/questions/7266848/downcasting-with-entity-framework">Downcasting with Entity Framework</a></p> <p>If this is what you are intending to do I would suggest that some part of the model being implemented should be reconsidered to avoid these situations.</p> <p><strong>Option 2</strong>: You have a list of child elements which belong as a group to a parent object (in this case of a super-type): </p> <p>In these cases you can load the parent, add the child to the parent and then save (at the parent level):</p> <pre><code>Child1 child = new Child(); Parent p = _context.Parents.Find(search based on ID) p.Children.Add(child); auditor.WriteObject(p); </code></pre> <p><strong>UPDATE: Option 3</strong></p> <p>Based on your comment of shared parent id: what you are talking about now is not a TPT implementation and you are breaking a rule here. In TPT you have a single ID which resides in the 'parent' table which is the primary key across all tables for each object. There should never be a case where two child objects (of any type) have the same primary key, and in all cases a childs primary key <strong>IS</strong> the parentID. Using less abstract terms might help remove the confusion: if the parent table is Animal and the child tables are Cat and Dog it becomes obvious that Cat and dog would not share a primary key (as they are different types. I think what you might be attempting to achieve is possibly the inverse: a Child should contain an instance of parent (using the terminology from your question).</p> <p>To say this one more way, if parentID is the primary key it will only exist in one branch of the hierarchy of objects, and will only serve to pull together the chain of inheritance which makes up this object. For example if I have an hierarchy like </p> <p>Animal->Dog->Poodle </p> <p>and I create a new poodle with ID=1, I will only ever have one set of records with ID=1, and it will be one row in each of Animal, Dog and Poodle. (and all three of these records are for the same Poodle object),</p>
    singulars
    1. This table or related slice is empty.
    1. POCode First TPT Inheritance - How can I supply the foreign key instead of EF creating the parent row for me?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USCommunity
    1. USMatthew
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POCode First TPT Inheritance - How can I supply the foreign key instead of EF creating the parent row for me?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COHi Matthew. Option 2 is what I'm after. I know that I could do what you suggested, however I'm hesitant to do so. I'm trying to keep Parent generic, and allow applications to extend it via children however they want. If I add a Children collection to Parent, Parent is no longer generic.
      singulars
      1. PO
      1. USjeff.eynon
    2. COYour comment actually leads me to think you are still talking about option 1 (or maybe mixing the idea of the two). What your code leads me to think is that in some cases the parent object already exists and you are 'extending' it as a child-type object (trying to set the parent ID). In your case could Parent be an abstract class? If the intent is to allow someone to later load a parent object, extend it as a child type, adding details, and than re-saving it, you need to follow the approach in option 1.
      singulars
      1. PO
      1. USMatthew
    3. COYou are right.... I typed too fast and meant to say Option 1. I can't delete the database row corresponding to the Parent type instance, because that row could be the parent to other child types. Meaning the parent row was created by saving another child type, and I want to latch onto it with this child type. Maybe my only option is to go back to a good old ADO.NET stored proc :)
      singulars
      1. PO
      1. USjeff.eynon
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload