Serializing objects with multiple relations

Help Developers
1

Hi Specklers,

I’m currently building a speckle connector for one of our in-house webapps. Thanks to this great tutorial I’ve been able to authenticate and now I’m at the point I’m going to serialize the objects to Speckle objects and send them to the speckle.xyz server.

The situation is as follows: I have a Django web-app and I’m using the specklepy client to send the data to the server with the token from the authentication workflow of the tutorial. The objects I’m trying to send are “Django-models” from PostgreSQL DB for which I’ve used a speckle class factory which automatically converts the “Django-models” to SpeckleClasses.

Within the serialization logic I’m using I’m able to convert all objects automatically to speckle objects, but I’m foreseeing issues when I would like to use the relations between the obects within the Speckle server.

Below you can find the DB-model where the issue occurs.

issue
issue919×841 16.3 KB

So I can keep the relations between the objects: FacilityCalculation > FacilityDesignOption > Facility > YearlyFacility. But the “horizontal relation” between “YearlyTrafficSector” and “YearlyFacility” would cause issues when serializing because it would duplicate the objects.

I’m trying to find a way to do this properly, and was wondering what the “Speckle” way of sending these kind of objects would be? It would be great if you could access “YearlyFacility” through: YearlyTrafficSector, Year and Facility for example without duplicating the YearlyFacility Obj three times, just like I can do with my Django ORM.

Thanks for reading and happy to explain more if unclear.

Cheers, Dirk

4 Likes
2

Ha, cross coupled references strike again! Okay, so, off the top of my head:

If you mark the fields that hold YearlyFacility objects as detachable (and the YearlyFacility object maps to a base-derived class), when Speckle will start decomposing it, it will be sent most likely once to the server, and for sure stored only once in the db. So basically you’re doing it properly already.

The cons are that it will make querying by any YearlyFacility prop difficult. So if the YearlyFacilities are something you’d wish to query a parent object by, e.g. myYearlyTrafficSector.yearlyFacility.year, if they’re detached, it’s becoming a bit more gruesome to filter by.

In that case, as long as the YearlyFacility doesn’t contain mountains of data, just let it be duplicated - it’s much easier for everyone, and any size inefficiencies are minimal over the wire (where it matters) because of us compressing things.

2 Likes
3

Decomposition API | Speckle Docs :duck: (I’m missing the rubberduck emoji, thanks for the proper docs on this as well!!)

Literally one second before you dropped the reply I managed to get the right data on the server. I haven’t start querying from the server yet, but there are no duplicates indeed :open_mouth: . Good to know that duplicates won’t matter that much, if it’s a big struggle I’ll just change it.

2 Likes
4

Haha, well done! (Ps: we also have a discord channel for rubber ducking internally, using the same :duck: emoji)

2 Likes