Looking for an efficient JSON/BSON library that supports a DOM, reader/writer interface and automatic serialization? Maybe this one has what you need...

Looking for an efficient JSON/BSON library that supports a DOM, reader/writer interface and automatic serialization? Maybe this one has what you need...
https://blog.grijjy.com/2017/01/30/efficient-and-easy-to-use-json-and-bson-library/

Comments

  1. I guess you made my day... I'll test this tomorrow on my Android project :)

    ReplyDelete
  2. Stéphane Wierzbicki Hope you'll like it. Let me know if you don't ;)

    ReplyDelete
  3. Erik van Bilsen What is the minimum version of Delphi required for this ?

    ReplyDelete
  4. Mocte Sandoval I have tested it with XE8, 10 Seattle and 10.1 Berlin. It may work on earlier versions, but I haven't tested that...

    ReplyDelete
  5. Erik van Bilsen​​​​ I'll let you know. I've just red your blog post (time is missing so much). I haven't found this but in your description but is your framework able to deserialize/serialize TList fields ?

    ReplyDelete
  6. Stéphane Wierzbicki The framework cannot (de)serialize generic collections. But it can serialize dynamic arrays. So you can do TList.ToArray and serialize that (depending on type T). Or you could write a custom serializer (as discussed at the very end of the blob post)...

    ReplyDelete
  7. Another gem among Delphi open source libraries.

    ReplyDelete
  8. This is really nice, thank you for sharing!
    But I have a question: If you have a class T with a member of the same type T, doesn't the GetOrAddSerializer() and the following class-structure-parsing-chain end up in a loop?
    GetOrAddSerializer() > TClassSerializer.Create() > TStructSerializer.MapFields() > TFieldInfo.Create() > TVarInfo.GetSerializationProcs() > tkClass: GetOrAddSerializer()

    I haven't tested it yet, but what I've seen, seems like you only save the TypeInformation in FRegisteredSerializers after the finished rtti-parsing.

    But again: thank you! One of the best examples of RTTI handling!

    ReplyDelete
  9. Ludwig Behm You are absolutely right. Good call! And that by just examining the code! I'm glad you like the library though...

    I pushed a fix and added a new unit test for this situation. I now save the serializer to the registry BEFORE I set it up (and before calling MapFields). That way, a re-entrant call will return the already registered serializer instead of creating a new one over and over again until the stack blows up. Let me know if you agree with this fix.

    ReplyDelete
  10. Erik van Bilsen looks good to me. I would've used the already existing Initialize procedure. But this will do it with fewer api changes, too.

    I tried porting the entire TgoBsonSerializer and the JsonWriter to C++ without BSON and type representations. So yes, I like your work very much - learned a ton about the RTTI and got serious headaches about the inconsistencies between Delphi and C++.

    ReplyDelete
  11. Erik van Bilsen another thought: Is there any pointer related information in the RTTI?
    Example: class Ttest { GUID value; GUID *pointerToValue;};
    In the example both fields would be of TypeKind tkRecord.
    But how can we distinguish if the fields and properties are pointer or not?
    Do you have already thought of that or just assumed that every TObject is a pointer and everything else isn't?

    ReplyDelete
  12. Ludwig Behm Actually, in your example, the second field would be of TypeKind tkPointer, and you would have to drill down further to find out the actual pointer type. The library doesn't support serializing pointers since it introduces some issues. Serializing a pointer is possible by dereferencing its value and storing that. But deserializing a pointer is more problematic. What should it do if the pointer is nil? Should it ignore it? Should it use GetMem to allocate some memory for the pointer? This makes serializing pointers less intuitive and error prone.

    Of course, you can always write a custom serializer to serialize records/classes that have pointer fields. Or fork the repo and add your own support for serializing pointers inside the library.

    ReplyDelete
  13. Are you sure that this would be a tkPointer? Because this would mean there is another incompatibility between C++ and Delphi. I just tested in 10.1(Berlin) that pField->FieldType->Kind is in both cases tkRecord.
    Same can be said for a simple int and int* wich are displayed as tkInteger.

    ReplyDelete
  14. Ludwig Behm I tested this yesterday and Delphi 10.1 says it is a tkPointer (as it should).

    ReplyDelete
  15. That's funny... so there is a difference between a C++ pointer and a Delphi pointer. Hmm... let's try the clang compiler^^

    ReplyDelete

Post a Comment