|
Description:
|
<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
|
