Doctrine value objects about money HOT 9 CLOSED

I am using this. I ended up creating a MoneyBundle tailored to the needs of that specific project.

<?xml version="1.0" encoding="UTF-8"?>
<doctrine-mapping xmlns="http://doctrine-project.org/schemas/orm/doctrine-mapping"
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                  xsi:schemaLocation="http://doctrine-project.org/schemas/orm/doctrine-mapping
                          http://www.doctrine-project.org/schemas/orm/doctrine-mapping.xsd">
  <embeddable name="Money\Money">
    <field name="amount" type="integer"/>
    <field name="currency" type="currency" length="3"/>
  </embeddable>
</doctrine-mapping>

from money.

There were already a Doctrine Type which is removed now. The removed type can be found here. However it makes it a bit weird to store it in database, since the database value must be stored as string.

from money.

Storing it as a string makes perfect sense. I do that as default, unless I need to query the value -- and even in that case I might have both a money field with the string, and a split money_amount and money_currency field. Don't believe the normalisation hype :-)

In any case, I'm sure somebody has provided a doctrine embeddable for Money somewhere.

from money.

Well, I am sure you can understand why I say it is weird. Think about a distance measurement: you do not store it as a string with a unit. You specify a base and convert it if needed.

In case of currencies it is a bit hard, since the conversion rates are not simple(not just 10 for example) and are always changing. So from this point of view storing monetary values as string is ok.

In other cases (like an ecommerce site) the currency is not strongly tied to the actual value, since EVERY value has the same currency by default and usually this can be converted to another currency (with the CurrencyPair for example). So I would rather say storing integers is better when it is possible.

from money.

since EVERY value has the same currency by default

Never make assumptions about other domains :-)
I've worked in ecommerce where the prices of products were not converted.
Eg EUR 599 vs GBP 479. Shop owners don't want to list GBP 476.54 as the
price. Doing any kind of querying on prices there would have been
pointless. Full text searches were done in solr.

Not all value objects are measurements by the way. But I guess that is
rather off topic here.

On 27 August 2014 20:07, Márk Sági-Kazár [email protected] wrote:

Well, I am sure you can understand why I say it is weird. Think about a
distance measurement: you do not store it as a string with a unit. You
specify a base and convert it if needed.

In case of currencies it is a bit hard, since the conversion rates are not
simple(not just 10 for example) and are always changing. So from this point
of view storing monetary values as string is ok.

In other cases (like an ecommerce site) the currency is not strongly tied
to the actual value, since EVERY value has the same currency by default and
usually this can be converted to another currency (with the CurrencyPair
for example). So I would rather say storing integers is better when it is
possible.

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

Mathias Verraes
[email protected]
http://verraes.net
@mathiasverraes http://twitter.com/mathiasverraes

from money.

I did not say correctly than, but usually (meaning open source Magento, OpenCart, Prestashop or the upcoming Sylius, etc) it is the case. Since I have no real experience with international ecommerce (there are not much international business like this in Hungary) I can't say for sure. However the point was to provide an understandable example where not storing the currency with the value is possible. And under these circumstances I still think storing integer values makes it easier to handle it as data. But I get it, in some cases it simply does not matter whether it is stored as integer or not. (Especially in PHP, where for example MySQL queries return all data as string)

from money.

This is an Entity, not a type. IMO it is wrong, because Money is a value object, which should rather be a type. Question: how do you handle the case when more than one entity requires a "money"? Do you even associate it to other entities?

from money.

@sagikazarmark - it is an embeddable thus a value object. not an entity. check the mapping file again.

from money.

Sorry, missed that.

from money.