Exception calling Get* on top level field without first defining it about ydotnet HOT 7 OPEN

@akatakritos from the update binary format perspective, the only information about root-level type passed is its name. The information about type of that structure is not passed as part of the update.

For root-level types, you're expected to create them after initialising the Document. The fact that this is not enforced behaviour is due to compatibility with Yjs API, which allows you to create them at any time for convenience, however it's advised to make it during Doc initialisation as well.

from ydotnet.

I will have a look, but it looks like something went wrong with the transmit, because it could not find the proper type. Therefore 0

from ydotnet.

Thanks! I think it transmitted; if I define the name field with remoteDoc.Text("name") after applying updates (right before opening the last ReadTransaction in the test), the field and its value can be successfully retrieved. Its like you have to explicitly define fields even if they come in from a remote sync

from ydotnet.

Could you ask that in the ycrdt repo. I am actually not sure right now

from ydotnet.

Sure! I'll see if I can figure out a reproduction using straight rust. Thanks!

from ydotnet.

https://www.bartoszsypytkowski.com/yrs-architecture/

These types can be nested in each other according to their limitations. Unlike primitive values they can also be assigned to the document itself (using their unique names for retrieval) and obtained right from it. Shared objects created straight at the document level are called a root level types and have a very interesting characteristic - their actual type is only a suggestion on how to present their content

...

This structure also enables to reinterpret root-level types eg. you can read a Text as an Array (to change its materialized type to a list of characters) or XmlElement as a Map (and be able to read only its attributes). Just like with any other kind of weakly typed systems you should use these capabilities with caution.

My interpretation of this is that it's by design to get a 0 back from rust. Top level properties are flexibly typed, if you don't declare that it's an Array or whatever it doesn't know how to interpret it.

Maybe we should keep throwing here but perhaps special case the 0 and throw a message informing the user to declare the type before trying to read it?

Or add an enum element for Undeclared = 0? That might just be an implementation quirk though

from ydotnet.

Thanks for the info! That's basically what I've come to understand. Maybe the only improvement this issue could represent is a slightly clearer exception message that guides the user towards declaring the field at Doc init time.

from ydotnet.