Closed iamNoah1 closed 2 years ago
I faced the same issue, and as workaround I'm cleaning my entities prior to send them remotely. As you can see below:
seneca.add('role: db,cmd: persist', (msg, reply) => {
var movie = seneca.make('movie')
movie.title = msg.title
movie.save$(function(err, saved_movie){
if(err){
reply(err, null);
} else {
reply(null, seneca.util.clean(saved_movie))
}
})
})
"Clean" removes all $ properties/functions from the entity, and the client is no more trying to call make$.
Hope this helps, Regards, Jérôme
Thanks for the workaround ... worked like a charm 👍
I assume this is not desired behavior?
FMHO this kind of behavior is application dependant and the choice to send entity remotely must be left to the developer. By the way I don't have tested it, but I'm not sure what will be the behavior when using an entity remotely:
If I'm understanding correctly, the framework is trying to serialize and deserialize an entity, but the entity/plugin isn't defined in the remote system?
Should the framework maybe indicate more about an entity not being loaded instead of an arbitrary error?
Added a comment to https://github.com/jeromevalentin/seneca-transport/commit/465e27ec9169106c95ab9dc1c096bc1b1d426a20, which seems like a good start to fixing the issue.
workaround is load seneca-entity
plugin
Hey guys,
transport-utils.js seems to have problem while responding with an entity created with the Seneca Data Entity API. It tries to invoke seneca.make$(raw) in line 487 and crashes with the following stracktrace (at least for me).
TypeError: seneca.make$ is not a function at internals.Utils.handle_entity (/Users/noa/Desktop/Workspace/stash/seneca_playground/node_modules/seneca-transport/lib/transport-utils.js:487:19) at internals.Utils.handle_response (/Users/noa/Desktop/Workspace/stash/seneca_playground/node_modules/seneca-transport/lib/transport-utils.js:82:19) at /Users/noa/Desktop/Workspace/stash/seneca_playground/node_modules/seneca-transport/lib/http.js:148:25 ...
Some additional Stuff
Server:
Client:
Package.json:
It would be nice if you could verify this. Thank you
Cheers Noah