Decimal data types in Service builder

[Pete Helgren, modificado 11 Anos atrás.]

I was kind of surprised that SB doesn't support decimal data types in version 6.0.x so my first question is: Is that true? Decimal data types aren't supported? Based on my research it looks like that is indeed true but rather than editorialize on the short-sightedness of the omission,I'll focus on the solution. One workaround is suggested here:

http://issues.liferay.com/browse/LEP-841

In it the OP says "I've just done a quick and dirty test and all I needed to do was use type="java.math.BigDecimal" in my service.xml and then modify the ext-hbm.xml to have type="big_decimal" in the appropriate place" I understand the part where you use the BigDecimal type in the SB xml but what about the ext-hbm.xml file? Where do I find the ext-hbm.xml (or where do I put it?). And what would be "in the appropriate place" ?

It is always helpful to post a *complete* solution when a problem is solved, so can someone help fill in the blanks? Where should the ext-hbm.xml be and what is the "appropriate" entry in it?

Thanks!

[David H Nebinger, modificado 11 Anos atrás.]

SB supports double and float types, but beyond that you're on your own.

I believe there is an enhancement request in place to support decimal types, but it either hasn't received a big push from the outside or has not been coded up and submitted. If I had to guess, I'd say that Liferay focused on providing the basics (along w/ what they needed to get SB done) and did not look towards implementing a complete solution. The biggest issue that you face trying to create general database-agnostic tools is dealing w/ differences in how (if) the types are handled.

As you can see by the ticket though, this request goes all the way back to Liferay 3.6.1. The ext-hbm.xml file is appropriate for older versions of Liferay, but not 6.0.x.

You can try modifying your generated src/META-INF/portlet-hbm.xml, but you won't find corresponding support class in com.liferay.portal.dao.orm.hibernate to help you here...

[Pete Helgren, modificado 11 Anos atrás.]

Thanks David. Pretty interesting that common database types still haven't made it into the SB code base. I took the easy way out and had the view modified to add casts to character data so that SB would be happy with it but it would be nice if I didn't have to keep working around these limitations. As a DB interface, you'd think the SB would support all ANSI SQL data types.

[David H Nebinger, modificado 11 Anos atrás.]

You should remember that SB was created primarily to satisfy Liferay's needs (support exposing data access methods to third-party portlets), not everyone's needs.

As mentioned in the ticket, Liferay uses doubles for their shopping cart implementation, so for them it is not an issue...

[Pete Helgren, modificado 11 Anos atrás.]

I am not sure I was aware that was the original intent. So I am curious then, what would be the correct approach to database access in Liferay? If SB was not designed nor enhanced to meet the "pedestrian" need of database access, then what would be the proper approach? Clearly Hibernate plays heavily but I haven't been on the platform long enough to know how DB access was done before SB. Should I look at getting SB out of the picture and learn more about the Hibernate layer and how to access it directly? Is there any value in going there?

I can work around the limitations of SB if I have to, but if there is a better way to build portlets that access an external DB (which is what I use SB for) then perhaps you could point me to it. Just curious and willing to try better approaches if they exist.

Thanks again for weighing in.

[David H Nebinger, modificado 11 Anos atrás.]

I would probably see if double fills your needs, since SB supports doubles. You may need to marshal back and forth between double and BD, but it may be a workable solution in the mean time... If double does not support the capacity you need, there's always String marshalling...

[Fernando Fernandez, modificado 5 Anos atrás.]

David H Nebinger:

(...)  Liferay uses doubles for their shopping cart implementation, so for them it is not an issue...

This seems a bit naive... Business systems , sooner or later, will have rounding problems with floating point arithmetic. Just imagine 2000 items in the shoping cart, calculating VAT for each one and calculating final VAT for the total amount of the invoice. There's a significant risk of the two totals being different because of small rounding errors. That's why business programming languages since COBOL had non-floating point decimal datatypes. 

 

HTH

 

Fernando 

[David H Nebinger, modificado 5 Anos atrás.]

Hey, I never said I agreed with not having decimal types...  I just said that Liferay only needed doubles for some of their standard stores and, without a real need, they hadn't implemented.  For their purpose, the double support was just fine.

But I never said it was a good or right decision; in fact I already voted on your ticket because I can see the value in it.

[Fernando Fernandez, modificado 5 Anos atrás.]

A feature request for this has been created on LPS-91620.

[Amos Fong, modificado 5 Anos atrás.]

Hey guys,

It looks like this was already done in https://issues.liferay.com/browse/LPS-78477

[Fernando Fernandez, modificado 5 Anos atrás.]

Yep. Just confirmed it. Someone should let the IDE know about it, since it displays an error when you choose BigDecimal as the columns type. But the gradle task compiles and the columns is finally created as a Decimal(30,16).

[David H Nebinger, modificado 5 Anos atrás.]

You could either open a ticket on issues.liferay.com or post a message to the IDE category in the forum...

[Gregory Amerson, modificado 5 Anos atrás.]

David H NebingerYou could either open a ticket on issues.liferay.com or post a message to the IDE category in the forum...

Looks like it was recently created: https://issues.liferay.com/browse/IDE-4559