Newbe Dev Stack

Answer : I've found the solution by myself, to add a custom field after the serialization has been done we've to create a listener class like this: <?php namespace Acme\DemoBundle\Listener; use JMS\DiExtraBundle\Annotation\Service; use JMS\DiExtraBundle\Annotation\Tag; use JMS\DiExtraBundle\Annotation\Inject; use JMS\DiExtraBundle\Annotation\InjectParams; use Symfony\Component\HttpKernel\Event\PostResponseEvent; use Acme\DemoBundle\Entity\Team; use JMS\Serializer\Handler\SubscribingHandlerInterface; use JMS\Serializer\EventDispatcher\EventSubscriberInterface; use JMS\Serializer\EventDispatcher\PreSerializeEvent; use JMS\Serializer\EventDispatcher\ObjectEvent; use JMS\Serializer\GraphNavigator; use JMS\Serializer\JsonSerializationVisitor; /** * Add data after serialization * * @Service("acme.listener.serializationlistener") * @Tag("jms_serializer.event_subscriber") */ class SerializationListener implements EventSubscriberInterface { /**...

Answer : I've found this page on their github repo, I'll just paste the content here. Recommended approach for saving a model There are two main approaches for serializing and restoring a model. The first (recommended) saves and loads only the model parameters: torch.save(the_model.state_dict(), PATH) Then later: the_model = TheModelClass(*args, **kwargs) the_model.load_state_dict(torch.load(PATH)) The second saves and loads the entire model: torch.save(the_model, PATH) Then later: the_model = torch.load(PATH) However in this case, the serialized data is bound to the specific classes and the exact directory structure used, so it can break in various ways when used in other projects, or after some serious refactors. It depends on what you want to do. Case # 1: Save the model to use it yourself for inference : You save the model, you restore it, and then you change the model to evaluation mode. This is done because you usually have BatchNorm and Dropout layers...