In Mstn CE, users can now reference the new Navigator i.model format that is based on SQlite... its 'secret sauce'. The file sizes are hugely smaller, and I think that they load faster as well although I am told that this should not be the case.
I am wondering if there are plans to adopt this more database friendly format for OPMS in future.
1. OPMS seems to work like Bentley Map's model server, based on Oracle Spatial. All the dgn elements are converted to and from a database format that is not bound by the file storage structure. This allows all kinds of nice parametrics and propagation to happen... easier. The cost would be the conversion and transaction check-in/out process that needs to happen every time a user needs to get at his data.
I think that OPMS now allows the user to keep the checked-in dgn on his local folder and synch to OPMS after he loads the dgns. Why not just use the i.model format which is a database file?
"To take advantage of this wonderful tool, Bentley joined the SQLite Consortium and embarked on a multi-year project to transform all of the information in DGN based i-models into an SQL schema based on SQLite. In fact a mobile i-model is a SQLite file. That means that all information from DGN-based (and other formats) applications appears as normalized rows in a SQL database. And, that same file can be combined with any other SQL data source to be “joined” by business logic in SQL."
Hopefully, this will speed any syncs up because OPMS would be comparing two RDMS database formats and not one DB and one CAD format. The i.model would function as a database cache and deltas can then be sent using high level database short-hand over the WAN/LAN.
I understand that even using the GPU's to get order of magnitude speedups are possible using SQlite. Maybe one day, OPMS would be run on the cloud with racks filled with GPU's linked together to allow large in-memory databases.
2. SQlite is not designed as a client-server DBMS and doesn't do concurrent writes but it is apparently possible for it to function as the storage engine. Some may find this counter to the 'one big source or playing field' aims that OPMS is based on, I think that its no getting away from the fact that there are some 'natural' segmentation lines between the disciplines. QSlite supports sharding and PDMS has always been hierarchial. This would also provide a middle ground between the centralised datastore OPMS offers and the file (.ism, i.dgn, .dgn, .i-model, .dwg, .ifc etc etc) based world.
Bentley has always been about 'federating' file-based info. OPMS doesn't seem to do this very well at all, having to rely on a second tier of file-based workflows based on file based tools like Reference files/ XRefs to provide much needed interoperability. It has only recently provided an ISM-based connection to a handful of structural apps. Even the check-in/out dialog to OPMS has gotten more ISM-like.
...
Makes me wonder what workflow is actually using or benefiting from the 'one big repository' that OPMS provides.
I think that the whole OpenPlant DB-based experience needs to get more like Mstn's Ref-file based way of working. When the user checks components out from OPMS, there should be an option to 'reference' the components as read-only elements. This should help minimise the silly transaction check in procedure and the overheads, ie the whole OPMS SQLServer set up! If you are working on the structure, you work check the structure in the area you want to work on in edit mode, and check the piping, civils, arch components out in read only mode. OPM automatically groups and adds the different piping, civils etc components as separate Ref attachments by discipline. Why make OPMS check for mods on check in/out when you know you won't make any?
If the user Activates a Ref because he needs to make a mod, then OPM then tries to tag those components with an advisory lock and flags the components up for the usual transaction process. If another has in the mean time checked out the components than there will need to be a change resolution Q&A session for those components. SQlite even has Shared Cache mode looks that like just the thing for this kind of working.
Why not use OPMS to provide the option to define multiple active/activated Ref attachments? Something that is already possible in Mstn. CE at some point?
As KB mentioned: "If you're in a session of MicroStation and have, say, 30–40 files that are all being referenced, and you need to edit some of them, in the past with MicroStation and AutoCAD there was one lock on one file. Now we can modify multiple files and have a transaction that spans multiple, independently lockable files. This is a big thing. You can have a large project spread across multiple offices and multiple computers and files."
OPMS may allow one user to access the whole repository for modification, but this will create chaos on a large ongoing database as the check-in / approval process would have to deal with a huge number of elements to be MANUALLY approved. This in fact means the changes would just be 'rubber stamped-through'... making the whole transaction management concept a joke. Need to provide for better flexible partitioning... like Ref-files, only improved.
Thank you for all your concern Dominic,
we have communicated it to expert channel. You would probably expect some suitable response here.
-Regards | Rahul Kumar
Regards,
Rahul Kumar
Product Engineer – Global Technical Support | Community Moderator