<FromGitter>
<Blacksmoke16> notice unchanged values are not included in the update query
<FromGitter>
<chasestory> @watzon yeah, I am in salt lake, sorry for the delay in response.. Crazy week at work!
zorp has quit [Ping timeout: 240 seconds]
<FromGitter>
<j8r> @Blacksmoke16 looks clean so far! You may have an idea on this: I'm doing a byte protocol - order matters. In my out-of-the-box (de)serialization library, I need to have this information somehow. Having an annotation on top of the object sounds good, like `Crystalizer::Object(fields_order: ["first_ivar", "another_one", "etc"])`. I like better than having to write one with an index on each ivar.
<FromGitter>
<j8r> Now, it would be great to have information about this order in the API docs – how would you do this?
<FromGitter>
<j8r> Maybe generate comments with macros...
<FromGitter>
<j8r> Ho, and for `String` and `Bytes` type, an annotation is needed to know the max size.
<FromGitter>
<Blacksmoke16> annotations arent documented in the API docs atm so yea
<FromGitter>
<Blacksmoke16> maybe you could add docs to the type, but not sure if that would totally override the other docs on it or what
<FromGitter>
<j8r> I wonder, it is possible to generate comments for an object with an annotation?
<FromGitter>
<Blacksmoke16> additionally maybe define some pseudo constant that you could apply the comment/order to
<FromGitter>
<j8r> I see what you mean by overwriting the comments
<FromGitter>
<j8r> Got an idea, the object annotation can have an option to tell that
<FromGitter>
<Blacksmoke16> you can do something like
<FromGitter>
<Blacksmoke16> since the em manages the states of the entities, if you were to do it twice, it wouldn't need to make a query the second time since its already managed