Hi,
I’m trying to use an SqliteTransport to store and query objects locally on my machine. Sending to it seems to work fine with a Send component - although sometimes the sending process hangs unpredictably - but receiving it with a Receive component throws 1. Solution exception:Object reference not set to an instance of an object. and the component message is Invalid.
Using a Receive from Transport component seems to work, however there is no way of retrieving all available object IDs, so these must somehow be known in advance, which is not possible in my case.
Any help would be welcome!
Thanks
Hi @TomSvilans, my suggestion would be to simply group all your objects under one before storing them using transports. It’s kind-of like creating your own “root commit object”.
I’ve seem to got it working on my end:
could you share with us a minimum reproduction example?
Thanks for the speedy feedback @dimitrie 
Sending/receiving transports works the way you show, but the issue there is that you need to give it a specific ID to return, whereas the normal Receive component would return all objects in a stream. It’s also advertised as working on transports, but when I hook up a transport to it, it fails. Perhaps it’s only meant to receive from streams after all.
Is there a quick way to query all object IDs in a particular transport? For example, the sending might happen in a script or another program than the receiving, meaning that the ID would not be immediately available without passing that separately, another way.
Could this be done with a GraphQL query through the API? The intent is to do stuff like return all objects with a particular name or property value from a local SqliteTransport - basically just using Speckle to locally store a model without any servers or accounts.
Looking through the code, looks like there already is a GetAllObjects function in SqliteTransport: speckle-sharp/SQLite.cs at 75002917987ce2c8d0303efd22682fe21df0fcc6 · specklesystems/speckle-sharp · GitHub
but it is marked internal.
Okay, i think i need to understand the use case a bit more! I’ll try and spell it out:
- No server, no accounts, no masters
- Storing any number of objects in a SQLite db (using transports) - you don’t want/need the commit abstraction and the grouping of them, as i tried in my example, is not useful
- Getting all the pokemons back, regardless of commits
Specifically, you’re just sending objects to a sqlite transport, and you basically want to retrieve all of them back without knowing their ids. Is this correct?
Essentially, yeah, that sounds like a way more succinct way to put it than I did 
Regarding commits, do Sqlite transports even make use of commits? Or is this left to the implementation of whatever object you are storing (i.e. having a base object with a commits property, as a stream would)?
Okay, gotchu. It’s bad news then: using the current transport nodes, i’m afraid this is going to be a bit impossible 
The get all objects function is internal, and it should stay that way - otherwise what you will be getting is all the chunks and decomposition bits that you probably don’t care about too much.
To make this work in the way you’d expect it to, it’s a bit of a larger change (but would be a welcome one when we look at Speckle as a developer platform - team note).
What we’d need is to add a few extra abstractions to transports or objects, and I’m unsure where this would sit properly yet. Brain dumps follow.
Solution 1: Adding the commit concept to transports
Currently the way to flag an object as “legit” is to create a commit (reminder: commits are wrappers around an object, usually a base containing a intelligent-ish structure of more objects coming from the source app) around it. This currently exists as a concept only on the server. Adding this as a convention to transports would be one way of solving things.
But it only solves part of the problem - you don’t seem to want to deal with commits. You want to send some beams and blobs and then just get those out afterwards from the db, no questions asked, YOLO mode. Totally legit 
Solution 2: Flagging objects as “legit”
To solve the latter, we’d need to differentiate between “legit” objects and any others that result from decomposition.
This way we could create a meaningful getAllObjects() function that actually returns all the objects you’re interested in.
We can’t do this from the serialisation process, as we don’t have enough context in there to make this call, but this could be done at the entry point in the transport save(list) function, where we can assume all objects passed in that list are “legit”.
thunking continues…
2 Likes
