<DavideD> emmanuel, one quick question about the TestHelper#extractEntityTuple
<DavideD> Andrea is working on the couchDb implementation and he has a problem with the BuiltInTypeTest
<DavideD> in the test BuiltinTypeTest#testStringMappedTypeSerialisation we check some values after the expected values has been converted to a Stirng and other values without converting them to string
<DavideD> for example the userId
<DavideD> If I'm correct the extractTuple should return values as String but the test fails because compares a String (actual value) with a Long (expected value) even if the String value of both is the same
<DavideD> It seem an error in the test

• whitingjr (~whitingjr@redhat/jboss/whitingjr) has joined #hibernate-dev
• whitingjr has quit (Quit: Leaving.)
• stliu has quit (Remote host closed the connection)
• whitingjr (~whitingjr@redhat/jboss/whitingjr) has joined #hibernate-dev
• whitingjr has quit (Client Quit)
• whitingjr (~whitingjr@redhat/jboss/whitingjr) has joined #hibernate-dev
  <emmanuel> DavideD: sorry got sidetracked by the internet
  <emmanuel> looking
  <emmanuel> DavideD: yes the test looks wrong
  <emmanuel> It was meant to only test built-in types that convert stuff into string
  <DavideD> is it ok if Andrea fix it by converting to String the expected and actual values?
  <emmanuel> Plus the extractTuple method should return Map<String,Object>
  <emmanuel> and not <String,String>
  <emmanuel> DavideD: no that does not look like a fix
  <DavideD> So the db should always remember the type of the object saved
  <emmanuel> DavideD: I would remove the test for userId and stockCount
  <emmanuel> these types are not meant to be strings
  <DavideD> Is The purpose of the test to assert values that should be saved as String in the db?
  <emmanuel> DavideD: I think so
  <emmanuel> but then dialects can override types so that's a bit of a mess
  <emmanuel> technicall we would only test the types and not necessarily how the NoSQL stores them
  <emmanuel> DavideD: the purpose is to test the string representation to be specific
  <emmanuel> but if a DB can store big decials in a native format
  <emmanuel> why not
  <emmanuel> can you open an issue to revisit this part of the tests?
  <emmanuel> In he mean time the lines 176 and 177 can go away
  <emmanuel> that's the ones posing problem I imagine