Add ooaofgraphics to schema

[leviathan747]

No description provided.

[john-tornblom]

Hmm, why is this needed?

[github-actions]

Unit Test Results

    4 files  ±0      4 suites  ±0   1m 21s ⏱️ -7s
241 tests ±0  241 ✔️ ±0  0 💤 ±0  0 ❌ ±0 
964 runs  ±0  964 ✔️ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit 6df29c2. ± Comparison against base commit 90b5144.

♻️ This comment has been updated with latest results.

[leviathan747]

@john-tornblom I want to use pyxtuml to do some model upgrade tasks. The flow would be:

1. Load a BridgePoint model
2. Traverse the instances and perform upgrades
3. Persist the instances to an .xtuml file
4. Load the model back into BridgePoint using the single file model import utility

I don't want to have to re-layout my diagrams after upgrade.

[leviathan747]

By the way, the majority of changes I have made to this repository are changes in the bridgepoint module (specifically prebuild). Do you think at some point it would make sense to separate that module into its own project? pyxtuml itself is more generic and it seems a bit as though it is mixing two different things.

[john-tornblom]

By the way, the majority of changes I have made to this repository are changes in the bridgepoint module (specifically prebuild). Do you think at some point it would make sense to separate that module into its own project? pyxtuml itself is more generic and it seems a bit as though it is mixing two different things.

Yea, that makes sense, I initially had a pyoal package, but merged that with pyxtuml for convenience (since no other action language was supported by bridgepoint at that time). I would wait until we have a candidate python prebuilder, e.g. MASL. Its difficult to design a good API with only one API user...

[john-tornblom]

Regarding ooaofgraphics. I wonder if this will impact performance or not, and if the graphics parameters introduced by this PR are required or optional? For example, If I have handcrafted instances without graphics, would that still be possible to execute in the oal interpreter?

[leviathan747]

Regarding ooaofgraphics. I wonder if this will impact performance or not, and if the graphics parameters introduced by this PR are required or optional? For example, If I have handcrafted instances without graphics, would that still be possible to execute in the oal interpreter?

I'll do some performance tests. Note that the change to the usage here is in the schema generator itself and not in prebuild. If you tried to load/parse a model without graphical instances, it would load the schema from schema.py (including the definitions of the tables for graphical instances), but when it loaded the model data there would be no difference

[john-tornblom]

Ahh, sorry, only schema gen, I thought it was in the prebuilder (reading of my phone). I withdraw that comment :)

[coveralls]

Coverage decreased (-0.03%) to 80.039% when pulling 6df29c2 on leviathan747:ooagrphics_schema into 90b5144 on xtuml:master.

[leviathan747]

Regarding performance, there is functionally no difference. I did a back to back test on a large model and saw no degradation of performance.

But now that I'm thinking about this, I realized something that makes me think I should withdraw this PR... pyxtuml automatically create new tables for any instances that it encounters and cannot find a metaclass for. I just did a quick test and confirmed that even without this change, if I load a model with graphical instances and then serialize the graphical instances are persisted. My original concern of losing graphics was unfounded!

Including graphics in the BridgePoint schema might at some point make sense, but at the moment I think it's completely superfluous so I am going to close the PR.

[john-tornblom]

Ah yes, instances of unknown classes will be persisted, but attributes of such instances are 'anonymous'.
If you need to access these attributes using pyxtuml, they are named '_i', where i is an index in the schema attribute list.