Strange Result - OmniBase bug or Date feature?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Strange Result - OmniBase bug or Date feature?

Peter Kenny

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

 

Peter Kenny

 

Reply | Threaded
Open this post in threaded view
|

Re: Strange Result - OmniBase bug or Date feature?

EstebanLM


On 23 Jun 2018, at 18:09, PBKResearch <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: Strange Result - OmniBase bug or Date feature?

EstebanLM


On 24 Jun 2018, at 10:02, Esteban Lorenzano <[hidden email]> wrote:



On 23 Jun 2018, at 18:09, PBKResearch <[hidden email]> 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