search

relativitydev / Gravity

ORM Framework for Relativity Custom Development
Other
16 stars 10 forks source link

Support non-dynamic object types #159

Open Arithmomaniac opened 5 years ago

Arithmomaniac commented 5 years ago

Right now, you need an object type Guid (as the input to RelativityObjectAttribute to define a Gravity class . This excludes all non-dynamic object types, such as saved searches and fields, from being present in a Gravity model as associated objects. At @Milyli, these field types frequently show up in configuration RDOs, limiting Gravity's usefulness.

We should allow object type to be defined by an ArtifactType as well for these scenarios (e.g. [RelativityObject(14)] for a field).

The fields themselves have Guids, so the other attributes would not need new overloads.

This might be easier to do after #158.

mrobustelli commented 5 years ago

Could we/should we do something with mapping? For example, come up with our own guids for the objects then if those guids are used, we handle them a special way. This way as those objects become supported by Relativity it would be a matter of just removing them from the mapping dictionary and everything should still just work?

Arithmomaniac commented 5 years ago

That would work as well.

mrobustelli commented 5 years ago

We are in agreement the reference should be by Name vs Guid for these objects.