Hey guys, we’re working with a pretty large library of geometric parts (branches) with separate versions (commits), of various classes (streams - walls, doors, fixings etc.). The parts are then nested into various assemblies (also streams), which finally make their way into projects (again streams).
Firstly, would it be better to flatten one layer of that hierarchy and use nested branches instead? I guess we could ultimately just make streams of streams and organise stuff that way, and rely on more specific queries and flatten the part / assembly hierarchy?.
Secondly, the way I’ve been testing in development (specifically to delete many streams) is to query 50 streams at a time, store them and the cursor, send a streams delete mutation, then get the next batch and so on and so forth. Still a little new to GQL, but this seems like the best way to do it at the moment, or am I missing something? Where does the limit come from?
For non-public Speckle.XYZ servers, that can obviously be forked and edited. I’d have to get back to you with info from the server team to answer if it is a DB technical limit question or DB saving from a DOS type of limit.
If you have such a server stream management issue to handle, there might be a way for you to track that in other ways than on demand. Even if there is a cron-like job to tabulate them on your end. Singular - or small batch - updates and deletes should be easier to handle that way
Thanks Jonathon, also for getting back so quick. I know what you mean - it really shouldn’t be the case that one creates or deletes that many at one time, I guess I was just testing with ways of pushing our library up in one go and kinda ran into it.
