Closed nickgeoca closed 7 years ago
Instead of "guessTypeFromString" why don't we have two types: one hex string, the other pure string. Both of these can be type-checked and passed on as bytes32.
@DoctorKhan Sounds good to me, I think I saw something like that in branch.
@OR13 how would you validate this type?
{
type: 'IPLD_OBJECT',
payload: {
name: 'hodor',
class: 'ogre',
inventory: ['axe']
}
},
@nickgeoca hey, sorry I failed to see this. I would not attempt to validate it. other than detecting that payload is an object and not an array.
Error handling and type safety to be added
What does this mean? "mostly the way that we convert js type to solidity safe bytes32, its not very well supported except for IPFS types."
Explanation https://github.com/transmute-industries/transmute-framework/blob/master/src/EventStore/Utils/Common.ts https://github.com/transmute-industries/transmute-framework/blob/master/src/EventStore/EventStore.ts#L102 so L102 is the begining of writeEvent this thing looks at a js type, and tries to convert it using those functions in common the issue is that we dont have many tests for this kind of thing, and I know for a fact that some of the types dont work (objects do, they become ipfs data) here are the tests https://github.com/transmute-industries/transmute-framework/blob/master/src/EventStore/EventStore.spec.ts they are pretty limited https://github.com/transmute-industries/transmute-framework/blob/master/src/EventStore/EventStore.mock.ts the issue is this: what happens when I try and write a string that is too large? or a floating point number? these should cause friendly errors but I am pretty sure they just cause explosions right now it would be nice to add some tests to show the error cases, and give us confidence that we can store things other than objects