update schema to base timestamp on integer #22
Conversation
|
Do you think this change introduces incompatibility issues? |
|
I do not believe so. @cortlandstarrett might have more to say, but without having intimate knowledge about the other MC's out there, I do not believe it will have large negative effects. |
|
We have now made this change in BridgePoint proper. So, any impact on
downstream tooling will need to occur anyway. I like keeping BP prebuilder
and pyxtuml prebuilder aligned.
…On Mon, Jun 29, 2020 at 2:17 PM Levi Starrett ***@***.***> wrote:
I do not believe so. @cortlandstarrett
<https://github.com/cortlandstarrett> might have more to say, but without
having intimate knowledge about the other MC's out there, I do not believe
it will have large negative effects.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#22 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAPGT3TVGMKHXINEYX3U4ADRZDLDJANCNFSM4OK2AR5A>
.
|
|
Sure, but this changes complicates the maintenance, and motivates a major version bump of pyxtuml. What was the motivation behind this change? I never really liked having both timer handling and time in the same EE to begin with. The OAL language has syntax for handling timers, just not implemented in bridgepoint (see Executable UML: A Foundation for Model-driven Architecture for examples). |
|
https://onefact.net/2020/05/12/panda-open-source-development/
https://github.com/xtuml/bridgepoint/blob/master/doc-bridgepoint/notes/11937_epoch/11937_epoch_ant.adoc
The above two links give the background. The even shorter answer is "time
arithmetic". String is pretty weak in that regard.
…On Mon, Jun 29, 2020 at 3:55 PM John Törnblom ***@***.***> wrote:
Sure, but this changes complicates the maintenance, and motivates a major
version bump of pyxtuml.
It would be nice to be able to support both to some extent, the .xtuml
files contains version-info (prefixed with "persistence-version: "), but
will be somewhat hacky imho.
What was the motivation behind this change? I never really liked having
both timer handling and time in the same EE to begin with. The OAL language
has syntax for handling timers, just not implemented in bridgepoint (see
Executable UML: A Foundation for Model-driven Architecture for examples).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#22 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAPGT3TLTSXTNGINVVDOND3RZDWRJANCNFSM4OK2AR5A>
.
|
|
Right. I would just have made a new package with EE+UserType out of this. I have several examples of similar stuff at: https://github.com/john-tornblom/mc_stdlib, working fine in both verifier and mc3020. But if you really feel the need to break backwards compatibility, I'll merge this. |
|
The change in MC-3020 is trivial. I vote we make this Right (numeric
rather than string).
…On Mon, Jun 29, 2020 at 5:19 PM John Törnblom ***@***.***> wrote:
Right. I would just have made a new package with EE+UserType out of this.
I have several examples of similar stuff at:
https://github.com/john-tornblom/mc_stdlib, working fine in both verifier
and mc3020.
But if you really feel the need to break backwards compatibility, I'll
merge this.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#22 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAPGT3TJXXOH2R6HSE2IIE3RZEAPRANCNFSM4OK2AR5A>
.
|
|
Okey, but where does strings fit in to this? |
|
String is the former core type for the timestamp UDT.
…On Tue, Jun 30, 2020 at 5:40 PM John Törnblom ***@***.***> wrote:
Okey, but where does strings fit in to this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#22 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAPGT3RQVBAKBKCHKMVLHY3RZJLWTANCNFSM4OK2AR5A>
.
|
|
Hmmm, isn't it |
|
Well, yes, inst_ref<Mapping>, which just meant, "special case this anywhere
you see it".
…On Tue, Jun 30, 2020 at 5:46 PM John Törnblom ***@***.***> wrote:
Hmmm, isn't it inst??
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#22 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAPGT3UIJQEK4A7BGTJ7AZLRZJMMBANCNFSM4OK2AR5A>
.
|
|
So, can the |
|
That would be feasible. But typically date types are structural, while a
timestamp is typically an integer referenced from some 'epoch'. We did not
change the handling of 'date'.
…On Tue, Jun 30, 2020 at 5:53 PM John Törnblom ***@***.***> wrote:
So, can the date type also be update? Then, could inst_ref<Mapping> be
removed/deprecated?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#22 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAPGT3SNKKTMRLZWVHUMM4DRZJNFPANCNFSM4OK2AR5A>
.
|
|
Yea, UNIX time can be captured by an integer, but it is not unusual with other representation of date and time, see, e.g., https://docs.python.org/3/library/datetime.html (object) and https://docs.python.org/3/library/time.html#time.clock_settime (64bit floating point number) |
|
Lets merge this into a version 3 branch, but also make sure we address related issues that might appear down the line before a stable major version bump appears on master. Sounds OK? |
|
That sounds good to me.
…On Wed, Jul 1, 2020 at 1:45 PM John Törnblom ***@***.***> wrote:
Lets merge this into a version 3 branch, but also make sure we address
related issues that might appear down the line before a stable major
version bump appears on master. Sounds OK?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#22 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAPGT3VHVTZ3XGCZCPOHNA3RZNY27ANCNFSM4OK2AR5A>
.
|
|
Install with: |
Recent changes to BridgePoint have made timestamp based on integer and not inst. Update the pyxtuml schema to reflect this.