[Smtk-developers] Changes to model manager

[Robert Maynard]

Just a clarification.

smtk::mesh::MeshSets are never stored in files and don't have UUIDS.
Recently I have come to regret that name for the class as it really
should be named something like smtk::mesh::View.

The reason for this is that a smtk::mesh::MeshSets reference numerous
meshes from the underlying database, which might or might not have the
optional UUID field. That is why the
smtk::mesh::MeshSets::modelEntityIds() returns a vector of UUIDS which
doesn't need to be the same length as smtk::mesh::MeshSets::size()

On Fri, Sep 15, 2017 at 2:43 PM, David Thompson
<david.thompson at kitware.com> wrote:
> Hi all,
>
> I've just merged changes to the model system into SMTK master; they are significant enough to warrant this e-mail. These changes are work towards SMTK 2.0 and particularly toward making the mesh, model, and attribute systems more consistent:
>
> + smtk::model::Manager now inherits smtk::common::Resource, just as smtk::attribute::Collection does. This means each model manager has a UUID and a URL (location) indicating where it is on disk.
>
> + smtk::model::Manager now stores smtk::model::Entity instances by mapping UUIDs to shared pointers instead of directly to instances. This is necessary because:
>
> + smtk::model::Entity now inherits smtk::common::ResourceComponent, just as smtk::attribute::Attribute does. ResourceComponents are managed via shared pointers and store their UUID directly.
>
> At some point,
>
> + smtk::model::Manager will be renamed smtk::model::Collection to match the attribute system.
> + smtk::mesh::Collection will inherit smtk::common::Resource.
>
> This way, each of the 3 main systems in SMTK (model, mesh, attribute) will each have resources (things stored in files) named Collection which contain components (model entities, mesh sets, attribute instances) that are all referenced by UUID.
>
> This merge also removes sparsehash storage as an option. We weren't using it, we weren't testing it, and it has different semantics than std::map for when iterators are invalidated. If anyone is really interested in it, speak up soon and we can revert it -- but I would prefer not to.
>
>         David
> _______________________________________________
> Smtk-developers mailing list
> Smtk-developers at smtk.org
> http://public.kitware.com/mailman/listinfo/smtk-developers