> On 23 Jun 2018, at 18:09, PBKResearch <pe...@pbkresearch.co.uk> wrote:
> 
> Retransmit with additional information: All tests with Windows 10 with all 
> recent updates
>  
> Hello All
>  
> I am experimenting with the version of OmniBase which Esteban Lorenzano 
> posted a few days ago. With corrections posted by Matias Moretto, who is 
> working on the same track, I have got the first five tests all green. On the 
> sixth test, OmniBaseTest>>#testEquality, I have run into a strange failure. I 
> don’t know whether it shows that OmniBase is not recovering data correctly, 
> or whether it is a feature of the way Date is implemented in Pharo. (I still 
> have Dolphin 6 on my machine, including OmniBase, and there the same test 
> passes.)
>  
> The test simply constructs a collection of various types of object, stores 
> the whole collection on the database, retrieves it and compares each 
> retrieved element with the corresponding element of the original collection. 
> One element is obtained by evaluating ‘Date today’, and that is the one that 
> fails. The test failure description is: ‘Got 23 June 2018 instead of 23 June 
> 2018.’ Using the inspector, I can see that the retrieved date differs from 
> the original in that the instvar ‘start’ has a Julian Day Number which is one 
> greater, but seconds as zero instead of 82800 and an offset of zero instead 
> of 1:00:00. In fact 82800 seconds is 23 hours, so all these add up to the 
> same start time, just differently represented.
>  
> To get round the failure, I changed the constructor of the test collection to 
> use ‘Date today printString’, which of course meant it worked perfectly. My 
> worry is whether in some other context the change of the innards of the 
> object might have an adverse effect. I don’t understand why the Date 
> constructor represents the start of today as 23 hours after 1 a.m. yesterday. 
> Is the change something OmniBase has done in storing and retrieving, or is it 
> due to the way the Date is reconstructed?
>  
> Just for fun, I used Fuel to serialize and re-materialize Date today; it did 
> not make any changes.
>  
> Does this reinforce Todd’s suggestion that OmniBase is not reliable, or is it 
> just a quirk?
>  
> Any ideas gratefully received


no idea about it but… feel free to send me a PR (and I will move the port to 
pharo-nosql group as is not “my” project) :)

cheers!
Esteban



>  
> Peter Kenny

Reply via email to