Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>In Nh, you can't use reference equality for detached instances. This stuffs you for using NH in clients that would like to use this behaviour (in my opinion this is the correct behaviour, NH doesn't depend on magic!) . </p> <p>In web apps or session based usages where you can go to the db in the scope of one ISession, I think I am correct in saying you can rely on reference equality. But in a smart client scenario, or more specifically, any scenario in which two ISessions are sharing an instance (one loaded from or inserted into the db, then passed to the second), you need the db id field(s) stored along with the instance.</p> <p>the second session below would no idea that the instance that it is being passed is has already been inserted and requires an update, and even if you changed it to an update, I assume I am right in thinking it is not going to know the DB ID of the class.</p> <pre><code>class SomeEntityWithNoId { public blah etc {} } class dao { void DateMethod() { var s1 = sessionFactory.OpenSession(); var instance = new SomeEntityWithNoId(); instance.Blah = "First time, you need to insert"; s1.Save(s1); //now instance is persisted, has a DB ID such as identity or Hilo or whatever s1.close(); var s2 = sessionFactory.OpenSession(); s2.Blah = "Now update, going to find that pretty hard as the 2nd session won't know what ID to use for the UPDATE statement"; s2.Update(instance); //results in boom! exception, the second session has no idea *how* to update this instance. } } </code></pre> <p>If you are concerned about the ID field(s), which you are correct in thinking is largely useless for anything other than persistence concerns, you can make them private, so at least this behaviour and semantics are encapsulated. You might find that this approach puts some friction into TDD. </p> <p>I think you are correct about the ID maps with regards to NH at least. If the instance is transient when it is first attached to the session, your type does not need to store its db ID in a field. I think the session will know how to manage it's relationship with the db. I'm sure you can bust out a test to prove this behaviour ;p</p>
    singulars
    1. This table or related slice is empty.
    1. PODDD: Primary keys (Ids) and ORMs (for example, NHibernate)
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USNoel Kennedy
    1. USNoel Kennedy
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI agree with your post, but I do not think the provided example (2 subsequent sessions with one object) a common use case for the NHibernate. Sending objects from server to client is another story, but in this case they might be DTO or have a custom serializer that allows Id to be sent/received.
      singulars
      1. PO
      1. USAndrey Shchekin
 

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