> On 24 Jun 2018, at 10:02, Esteban Lorenzano <esteba...@gmail.com> wrote:
> 
> 
> 
>> On 23 Jun 2018, at 18:09, PBKResearch <pe...@pbkresearch.co.uk 
>> <mailto: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) :)

and btw if you or anyone else wants to take the responsibility of keeping that 
project, I will gladly add you as maintainers of it. As I said, I’m not the 
right one to do it since I do not work with OmniBase in general… even if I 
wanted to create a layer on voyage for it (also a possible sub-project I 
recommend to look at it) 

cheers, 
Esteban

> 
> cheers!
> Esteban
> 
> 
> 
>>  
>> Peter Kenny

Reply via email to