Force datetime format to include microseconds about common HOT 9 CLOSED

@prolic Any idea to really force the correct format? I can only add a note in the MessageFactory and MessageConverter interface. Maybe the MessageConverter should return a DTO or some kind of value object instead of a plain array? This way we would be able to control the structure.

Damn, or we have to change the signatures of the interfaces but this would mean more TODO.

MessageFactory

/**
 * @return mixed //The custom message object
*/
public function createFromRawMessage(Message $message);

MessageConverter

/**
 * @param mixed $customMessage
 * @return Message
 */
public function convertToRawMessage($customMessage);

Message

interface Message
{
  public static function fromArray();

  public function toArray();

  //...
}

from common.

This message problem drives me crazy. The best thing would be a PSR for messaging like we have now for request/response with PSR-7. But this would take years ...

On the one hand commands and domain events are application / domain specific. So users want to use their own implementations and don't want to extend base classes from a third-party library like prooph. These are valid concerns so I really want to support custom message objects with all components. prooph/service-bus has absolutely no problem with this. But the event store adapters need to rely on a basic contract so that they can convert event objects into plain PHP types and back. I thought that the interfaces Message, MessageFactory and MessageConverter tackle the problem. But the datetime formatting problem smells like they don't.

from common.

Just found, that MySQL supports datetime with microseconds only from 5.6.4 on, see: http://dev.mysql.com/doc/refman/5.6/en/fractional-seconds.html.
I need to check whether or not doctrine can handle this correctly.

As for the PHP-part, I need to think about this a little.

from common.

Currently, the doctrine adapter stores the datetime as a string and uses the formatted value returned by MessageConverter to do so. That means the adapter would not be effected as long as we keep the MessageConverter as-is and just change the standard format in DomainMessage. You can also easily order by ISO8601 (+microseconds). I see no need to use a datetime column type to store the date.
But yes, would be great if you think about the problem too. Maybe we can find a good solution together. I think about the problem for a long time now. Whatever way I try at some point I encounter a problem.

Here are the things that should be supported by the solution:

• Allow dispatching custom message objects with prooph/service-bus
• Persist custom message objects with prooph/event-store
• Dispatch messages async with the help of a message producer (like an amqp adapter 😄 )
• Use the event store as a worker queue
• Provide a good foundation for advanced tools like message bus monitoring, Z-Ray integration, Zend Developer Toolbar integration, Saga-Management, etc.

The first two points require a very basic interface or ideally no interface at all.

However, all other points need a message contract to work together. IMO the current Message interface includes all information and functionality that need to be available for these advanced tools.
And MessageFactory + MessageConverter take over the task to convert messages from/to array so that low level adapters like message producer or event store adapters can persist them or send them over the wire.

from common.

Just some random thoughts on this:

The message factory is not a problem at all. Problem comes from the message converter. The message converter is only used in the event store adapters.

The message converter currently says:

/**
 * The result array MUST contain the following data structure:
 *
 * [
 *   'message_name' => string,
 *   'uuid' => string,
 *   'version' => int,
 *   'payload' => array, //MUST only contain sub arrays and/or scalar types, objects, etc. are not allowed!
 *   'metadata' => array, //MUST only contain key/value pairs with values being only scalar types!
 *   'created_at' => string, //formatted \DateTime
 * ]
 *
 * @param Message $domainMessage
 * @return array
 */

But perhabs the message converter should say:

/**
 * The result array MUST contain the following data structure:
 *
 * [
 *   'message_name' => string,
 *   'uuid' => string,
 *   'version' => int,
 *   'payload' => array, //MUST only contain sub arrays and/or scalar types, objects, etc. are not allowed!
 *   'metadata' => array, //MUST only contain key/value pairs with values being only scalar types!
 *   'created_at' => \DateTimeInterface
 * ]
 *
 * @param Message $domainMessage
 * @return array
 */

After the message converter did his job, we apply a message validation. We need to check whether or not the message converter did his job correctly and returned the desired values and correct format, because we can't rely on the message converter to be bug-free (as it can be a userland implementation).

The formatting from \DateTimeInterface to a string (doctrine adapter) or a \MongoDate (mongo db adapter) can be done in the adapter itself.

from common.

You're absolutely right. I had something similar in mind but then thought it is not nice when the message converter is asked to return native PHP types but a \DateTime for created_at. Looking at your interface definition now it isn't a problem. A \DateTimeInterface can be considered a native PHP type. We should do it exactly this way. I'll prepare a PR for prooph/common and then we align the adpaters. Ah wait, I will include an assertion helper into my prooph/common PR. So we don't need to duplicate the assertion logic. Currently, only the adapters use the MessageConverter but the message producer for prooph/service-bus will need the same functionality soon.

from common.

Great ;-)
Am 25.08.2015 14:16 schrieb "Alexander Miertsch" [email protected]:

You're absolutely right. I had something similar in mind but then thought
it is not nice when the message converter is asked to return native PHP
types but a \DateTime for created_at. Looking at your interface
definition now it isn't a problem. A \DateTimeInterface can be considered a
native PHP type. We should do it exactly this way. I'll prepare a PR for
prooph/common and then we align the adpaters. Ah wait, I will include an
assertion helper into my prooph/common PR. So we don't need to duplicate
the assertion logic. Currently, only the adapters use the MessageConverter
but the message producer for prooph/service-bus will need the same
functionality soon.

—
Reply to this email directly or view it on GitHub
#36 (comment).

from common.

thanks for healing my pain in the head 😄

from common.

@prolic prooph/common v3.5 is released. We need to require this version as a minimum in the adapters.

from common.