[SERVER-1393] Support decimal numbers Created: 11/Jul/10 Updated: 15/Nov/21 Resolved: 06/Jun/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Usability |
| Affects Version/s: | None |
| Fix Version/s: | 3.3.8 |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | karl seguin | Assignee: | Geert Bosch |
| Resolution: | Done | Votes: | 141 |
| Labels: | bson2 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Major Change | ||||||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | Integrate+Tuning 16 (06/24/16) | ||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: |
Alex Gadea, andy, aochen, Ben Bernard, Benjamin M, Brian Ciomei, Carlos Gutiérrez, Christoph Menge, Colin Mollenhour, Daniel Goldman, Darin Cummins, Denis Robert, Dwight Merriman, Eliot Horowitz, Firoz Ansari, Geert Bosch, Githook User, James Tan, Joe, Johnny Shields, karl seguin, Karl Seguin, Marco Guidi, Mikael Nousiainen, Nicola Iarocci, Nikki Locke, NOVALUE Mitar, Oleg, Paul Harvey, Rei Roldan, Remon van Vliet, Scott Hernandez, Scott Rehlander, Sherif Sabry, Vladimir Dimitrov, Ygor Lemos
|
||||||||||||||||||||||||||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
Add a new BSON type for decimal numbers in MongoDB 3.4. This type will use the decimal128 format as defined by the IEEE 754 standard and support up to 34 decimal digits and a range from -9.999999999999999999999999999999999×10^6144 to +9.999999999999999999999999999999999×10^6144. Decimal values will be treated like any other numeric type, and compare and sort correctly with other types based on actual numeric value. Operations on decimals are implemented in accordance with the standard, so a value of 0.10 will retain its trailing zeros while comparing equal to 0.1, 0.10000 etc. Original description: Please consider adding support for arbitrary-precision numbers. A lot of applications consider precision as a mission critical component and lack of support for high precision numbers makes it impossible to use MongoDB. |
| Comments |
| Comment by NOVALUE Mitar [ 08/Jun/16 ] | ||||||||||||||||
|
Thanks for this measurement! | ||||||||||||||||
| Comment by Geert Bosch [ 08/Jun/16 ] | ||||||||||||||||
|
In actual BSON documents, a field like x : NumberDecimal("0.02") will take 1 byte for the BSON type, 1 byte for 'x', 1 zero byte to terminate the name and 16 bytes for the 128-bit decimal, for a total of 19 bytes. The same field would take 11 bytes for a double. For documents including an _id field with an ObjectId, the total document size is 41 bytes for decimal and 33 for double and 22 bytes for a document with just _id. By default, MongoDB uses the "snappy" compression method. As a test I inserted documents as above with random decimal and double precision numbers between 0.00 and 9999.99 and checked final storage sizes.
So, with default compression, decimal numbers take about 3 bytes more than doubles. | ||||||||||||||||
| Comment by NOVALUE Mitar [ 07/Jun/16 ] | ||||||||||||||||
|
How does this interoperate with compression? Are those values compressed when possible? | ||||||||||||||||
| Comment by Geert Bosch [ 06/Jun/16 ] | ||||||||||||||||
|
Support for the decimal128 data type, supporting decimal values with up to 34 digits of precision, is now fully implemented including indexing and aggregation support. | ||||||||||||||||
| Comment by Githook User [ 22/Apr/16 ] | ||||||||||||||||
|
Author: {u'username': u'GeertBosch', u'name': u'Geert Bosch', u'email': u'geert@mongodb.com'}Message: | ||||||||||||||||
| Comment by Githook User [ 22/Apr/16 ] | ||||||||||||||||
|
Author: {u'username': u'GeertBosch', u'name': u'Geert Bosch', u'email': u'geert@mongodb.com'}Message: | ||||||||||||||||
| Comment by Githook User [ 22/Apr/16 ] | ||||||||||||||||
|
Author: {u'username': u'GeertBosch', u'name': u'Geert Bosch', u'email': u'geert@mongodb.com'}Message: | ||||||||||||||||
| Comment by Geert Bosch [ 11/Feb/16 ] | ||||||||||||||||
|
We are planning to add a new BSON type for decimal numbers in MongoDB 3.4. This type will use the decimal128 format as defined by the IEEE 754 standard and support up to 34 decimal digits and a range from -9.999999999999999999999999999999999×10^6144 to +9.999999999999999999999999999999999×10^6144. Decimal values will be treated like any other numeric type, and compare and sort correctly with other types based on actual numeric value. Operations on decimals are implemented in accordance with the standard, so a value of 0.10 will retain its trailing zeros while comparing equal to 0.1, 0.10000 etc. Please continue to watch this ticket for updates on these changes. Thanks all for your patience! | ||||||||||||||||
| Comment by Johnny Shields [ 31/Dec/15 ] | ||||||||||||||||
|
Hi MongoDB team, may we please get a comment on this? BigDecimal is used in many applications (financial, etc). There are many half-baked solutions which attempt to solve this at the application layer (e.g. storing as string for reading + float for querying) but the problem would really be better solved in the DB itself. | ||||||||||||||||
| Comment by Sherif Sabry [ 22/Mar/15 ] | ||||||||||||||||
|
So it has been 5 years since the ticket was opened! I think it is safe to assume that this won't be fixed unless a miracle happens. | ||||||||||||||||
| Comment by Ygor Lemos [ 03/Feb/15 ] | ||||||||||||||||
|
Is there a hint of light for this issue in the near future (post 3.0) ? This is indeed a much needed feature for anybody dealing with financial data. The solutions above work but they are far from effective, specially for using together with aggregations and sorting db-side... Are you guys seriously considering adding this datatype to the core db and the proper per-language decimal mappings on the drivers? | ||||||||||||||||
| Comment by Brian Ciomei [ 26/Sep/14 ] | ||||||||||||||||
|
This would also be extremely helpful for us. Many of the workarounds are reasonable but are major setbacks if we attempt to use the aggregations framework. | ||||||||||||||||
| Comment by Benjamin M [ 03/Sep/14 ] | ||||||||||||||||
|
I want to add my +100 here, too. At the moment I handle it using a fixed size precision (8 in this case): This way I can sort my documents inside the DB and it's also possible to create a sum which can be used inside my Java code: But of course I can't compare those sums easily inside the db, which is bad. Concerning the other answers: What about binary? Never thought about it. Can I sort / sum those values within a query? | ||||||||||||||||
| Comment by Joe [ 27/Jul/14 ] | ||||||||||||||||
|
Agreed, this is really a must have. All the work arounds are quite honestly hideous. | ||||||||||||||||
| Comment by Oleg [ 23/May/14 ] | ||||||||||||||||
|
Having a decimal type would be well. Anyway, now you have a few ways how can you store numbers: 5) binary array | ||||||||||||||||
| Comment by Darin Cummins [ 16/May/14 ] | ||||||||||||||||
|
As a side note, in the 30+ years I've been doing development, using floating point values have been rare and specific cases compared to other data types. If MongoDB defaulted decimal points values to fixed precision, and there was special annotation for using floating point values, it would make my day! | ||||||||||||||||
| Comment by Ben Bernard [ 16/May/14 ] | ||||||||||||||||
|
I agree with the above comments. I like MongoDB, and I want to love it, but it really, really needs a decimal datatype. I can't think of a single project I've worked on that did not need decimal storage. Seems like a glaring omission to me. | ||||||||||||||||
| Comment by Ygor Lemos [ 28/Apr/14 ] | ||||||||||||||||
|
Any news on this one? Storing financial / monetary data as cents / decimal fractions is getting dumb after 4 years... anything we could do to help accelerate this issue? Is there anything major blocking it? Tks | ||||||||||||||||
| Comment by Nikki Locke [ 28/Feb/14 ] | ||||||||||||||||
|
Yes, mongo is unsuitable for a large number of applications because of this lack. Bite that bullet! | ||||||||||||||||
| Comment by Scott Rehlander [ 20/Feb/14 ] | ||||||||||||||||
|
Agreed, this would be helpful for scientific applications. | ||||||||||||||||
| Comment by Daniel Goldman [ 19/Feb/14 ] | ||||||||||||||||
|
Financial applications aren't the only use case. Scientific applications that require support for specific precision / scale would also be supported with this change. | ||||||||||||||||
| Comment by James Tan [ 21/Nov/13 ] | ||||||||||||||||
|
FWIW, this is how eBay handles it: http://www.technology-ebay.de/the-teams/mobile-de/blog/mapping-bigdecimals-with-morphia-for-mongodb.html. | ||||||||||||||||
| Comment by Darin Cummins [ 13/Aug/13 ] | ||||||||||||||||
|
I love how MongoDB is progressing and getting so much better with every release! However, this particular lack of functionality is a show stopper for us. We are making some large architectural changes in the near future and have been watching the MongoDB releases with anticipation. Almost all other NoSQL database support decimal types. We are going to be forced to make a decision soon and without decimal types it is doubtful that MongoDB will be on the list of possibilities. | ||||||||||||||||
| Comment by Vladimir Dimitrov [ 21/Feb/13 ] | ||||||||||||||||
|
Almost 3 years later and there is no solution to this? This is really a critical issue and narrows the use of this otherwise great DB a lot. | ||||||||||||||||
| Comment by aochen [ 08/Apr/12 ] | ||||||||||||||||
|
@Dwight Merriman | ||||||||||||||||
| Comment by Carlos Gutiérrez [ 05/Apr/12 ] | ||||||||||||||||
|
@Dwight Merriman 1 & 2 would be useful, but if 3 is easier to implement, it will solve most of the needs for storing money and inventory data. It could be: up to 16 decimal digits including 0 to 15 digits to the right of decimal. It could be stored using something like the old "Packed Decimal" format ( http://en.wikipedia.org/wiki/Binary-coded_decimal#Packed_BCD ), maybe with an extra byte for length and number of digits to the right of decimal. | ||||||||||||||||
| Comment by Darin Cummins [ 20/Jan/12 ] | ||||||||||||||||
|
Here is an example of how Postgresql describes their Arbitrary Precision Numbers: http://www.postgresql.org/docs/8.4/static/datatype-numeric.html (See section 8.1.2) | ||||||||||||||||
| Comment by Dwight Merriman [ 20/Jan/12 ] | ||||||||||||||||
|
so exactly what should it be for example which of these : | ||||||||||||||||
| Comment by Alex Gadea [ 06/Jan/12 ] | ||||||||||||||||
|
Wanted to add my +10 vote on this and agree with Karl's comments. I just had a large project choose to not use Mongo due to this glaring limitation. Lots of very large datasets exist in the financial world and its a shame that Mongo will be shut out of consideration due to this very basic issue. | ||||||||||||||||
| Comment by Nicola Iarocci [ 02/Jan/12 ] | ||||||||||||||||
|
This is indeed a show stopper for many financial/accounting applications. Actually I'm surprised this is not getting (or so it seems by the vague responses) the attention it deserves. | ||||||||||||||||
| Comment by andy [ 26/Oct/11 ] | ||||||||||||||||
|
I just wanted to clarify something - when we talk about arbitrary-precision numbers, we are also talking about arbitrary-size numbers. So for instance 32 or 64 (or 128!) bits integers are not good enough. There should be no limit in the size of a number whatsoever. Floats or doubles are also not suitable. When I store the number I care about, I want it to be saved exactly as I want it. See Java BigDecimal or PHP BCmath for reference implementations. You could even use libbcmath for this (LGPL license) if it makes sense. To recap, the DECIMAL data type should solve two problems:
Is there a time frame for this feature? | ||||||||||||||||
| Comment by Colin Mollenhour [ 18/Jun/11 ] | ||||||||||||||||
|
Agree 100% with Karl. Mongo's mantra seems to be centered around (actually says this on the homepage) "simplicity and power". Not having decimals definitely affects the simplicity of using Mongo for a large market. I suspect the reason this hasn't been given more attention is that due to MongoDb's schema-less nature there are additional challenges since you can't declare at the database layer that a field's value should be stored as "decimal", and then the fact that there is no native/standard for decimals in many languages including javascript, although there is actually a proposal for a decimal data type in ecmascript[1]. It doesn't appear to be going anywhere fast so I'm not holding my breath for 10gen to take this up.. It seems the two main use-cases are for 1) working with huge numbers, and 2) dealing with decimal math and the ensuing calculation errors. Example for [2]: db.test.update({_id:"math"}, {_id:"math", a:169.4}, true); My proposal to deal with the 2nd use-case is rather than implement a fully-fledged decimal data type, what if users could set a decimal precision per-collection (documents remain schema-less) that would apply to all mongo doubles before they were stored? E.g.: db.createCollection("invoices", {precision: 4}); Any floating point values in this collection would be rounded just like MySQL's decimal(16,4) for example. This certainly would not satisfy the requirements of a "professional financial system", but there are plenty of applications that still deal with arbitrary precision numbers in Mongo's target market and I think this solution would be sufficient in the large majority of them. Even MySQL's decimal used floating point math internally until 5.0 and that did the job for a lot of people despite not being ideal. [1] http://wiki.ecmascript.org/doku.php?id=proposals:decimal&s=decimal | ||||||||||||||||
| Comment by Denis Robert [ 19/May/11 ] | ||||||||||||||||
|
@Remon: I really don't see why you couldn't use MongoDB for financial apps (I certainly plan to do so). Of course, it's unlikely that MongoDB will be used as the datastore of record for transactions, but there's a lot more than just transactions in most financial applications. I think your view of the world is a little narrow here. In Java, BigDecimal is really nothing but a wrapper around BigInteger. Internal storage is just a integer. That's because there's really no difference between an integral type and a fixed-point type, other than the unit. As long as you convert all numbers to the base unit before doing calculations, there's no reason to have any issues other than over/underflow, and rounding issues which you can't avoid anyhow. But nevertheless, having a distinct fixed-point type is pretty important for any application that manipulates currency values, so I +1 this as well... | ||||||||||||||||
| Comment by Christoph Menge [ 08/Apr/11 ] | ||||||||||||||||
|
@Karl: I just couldn't agree more! In particular because I'm currently building a financial application with MongoDB and I'm quite happy with it. @Darin: We've been using the same workaround once, but it is really ugly when it comes to Map/Reduce: When multiplying two numbers, you'd have to divide the result by 100M – this gets really, really agonizing and is error-prone like hell. The C# driver serializes decimal to string which was a good decision I think: the numbers remain denormalized ("1.0" and "1.000" are different), but they can be used in map/reduce by prepending a '+' which forces JavaScript to convert to double. Of course, precision is still limited to double and normal queries are not available, but it worked out better for us than scaling the numbers. But eliminating the storage overhead and enabling queries on those numbers would still be great, of course. | ||||||||||||||||
| Comment by Darin Cummins [ 08/Apr/11 ] | ||||||||||||||||
|
I have to agree with Karl. I also work with financial data, albeit not in a "banking" type environment, and using the modifier operations to make changes is a huge plus. We currently use a 64bit integer to encode monetary values (with an assumed precision of 4 decimal points) and while it does work, it isn't as straight forward as you might think. (We were forced into this because the database we were using at the time would not handle anything but integers and floats). For example, if we want to escalate prices (stored as mentioned) by applying a percentage (also having to be stored as mentioned since they can also be a fraction) the result must be divided by 10000 (shifting the decimal point) to get the correct result. Sure, simple, but must be done EVERYWHERE in the code. Many database creators (SQL Server, PostgreSQL, etc.) have begun life without the ability to handle fixed decimal (NUMERIC) types with the same attitude that "it isn't needed". However, all of them eventually were forced to put it in because it solves a lot of problems for developers. | ||||||||||||||||
| Comment by Karl Seguin [ 22/Mar/11 ] | ||||||||||||||||
|
I just can't let the above FUD stand without a response. I hate to turn this feature request into some net-drama but... You aren't the only person with experience in financial systems and with financial companies. Your comment is as condescending as it is ignorant. It's called a two-phase commit and its extremely common in the relational world. If you've never had to do a 2 phase commit across databases setup and designed in the early 90s, then you should consider yourself lucky (or possibly not nearly as experienced as you think you are with financial systems). In fact, it's exactly this type of system in which MongoDB is so well suited for in large financial institution - to act as a persistence cache for a modern application, to proxy away dated and impossible to change centralized relational databases. There will be cases where MongoDB won't be the right tool for the job, but by adding support for base-10 floats, that list will shrink. | ||||||||||||||||
| Comment by Remon van Vliet [ 15/Feb/11 ] | ||||||||||||||||
|
I don't agree this is in any way a critical feature for MongoDB. Arbitrary decimals are not needed and actually a bad idea for the vast majority of use cases (read: I can't think of a single one). A few points : 1) Anything that requires absolute consistency concerning financial transactions shouldn't use MongoDB in the first place. Use the right tool for the problem. The lack of transactional isolation, rollbacks, etc make it less than useful for this kind of problem. Use a fully ACID RDBMS. 2) No professional financial system will ever use floating point values for currency representation for a plethora of reasons. 3) As someone who actually built a number of financial systems that require some interoperability with other services; you cannot actually use arbitrary precision decimals because, as this discussion points out, a lot of systems/languages don't have support for that data type. 4) Most financial systems I've worked on or with have a smallest unit of currency designed into the system and that (integer) value is used throughout the app. Usually 1/1000ths of the currency unit but for the sake of clarity just think of it as working with cents/pennies instead of euros/dollars. This hardly qualifies as "a complication". Basically all you're getting with arbitrary precision integers is an easier way to print them, nothing more. There's complete mathematical consistency between working with predefined units of currency and arbitrary precision numbers. In other words, your code will not be more complicated with the minor exception of the UI code which will need a single helper function to prettify the number. -1? | ||||||||||||||||
| Comment by Eliot Horowitz (Inactive) [ 12/Feb/11 ] | ||||||||||||||||
|
If you login you can vote on the left here. | ||||||||||||||||
| Comment by Firoz Ansari [ 12/Feb/11 ] | ||||||||||||||||
|
+1 vote for decimal data type. Is there any place where mongodb community can vote for a feature or request? | ||||||||||||||||
| Comment by Marco Guidi [ 10/Feb/11 ] | ||||||||||||||||
|
There is some news about it?? Work with decimal is really important, this features can't miss. If you deal with money you can't work with float or double. | ||||||||||||||||
| Comment by Christoph Menge [ 23/Oct/10 ] | ||||||||||||||||
|
Scott, Note that the large numbers correspond to long.MaxValue and long.MaxValue - 1. // This will FAIL [does not find any results], because the argument is apparently interpreted as double, and double's precision is insufficient to resolve the difference // This will return the expected 1 result. I believe at least one driver incorrectly implements this. | ||||||||||||||||
| Comment by Scott Hernandez (Inactive) [ 23/Oct/10 ] | ||||||||||||||||
|
Christopher: Javascript is not involved for queries (at least not the ones you used). It is used for MR and that is why having javascript support for all the data-types is important, but unrelated to this request. I don't know what language that is (maybe python), but in javascript there is no "long" variable/class. > long.MaxValue Here is a simple test from the shell (javascript) > db.test.insert({_id:1, val:NumberLong("123123123123")}) > db.test.find({val:{$type:18}}) //64bit signed value { "_id" : 1, "val" : NumberLong("123123123123") }> db.test.find({val:{$type:1}}) // 64bit fp (double – javascript number) { "_id" : 2, "val" : 123123123123 }> db.test.find( {val:123123123123}) { "_id" : 1, "val" : NumberLong("123123123123") } { "_id" : 2, "val" : 123123123123 }Everything seems fine > db.test.find({val:{$gt:123123123123}}) { "_id" : 3, "val" : 9223372036854776000 } { "_id" : 4, "val" : NumberLong("9223372036854774000") }> db.test.find({val:{$gte:123123123123}}) { "_id" : 1, "val" : NumberLong("123123123123") } { "_id" : 2, "val" : 123123123123 } { "_id" : 3, "val" : 9223372036854776000 } { "_id" : 4, "val" : NumberLong("9223372036854774000") }For reference here is list of types: http://bsonspec.org/#/specification, and you can see $type section here: http://www.mongodb.org/display/DOCS/Advanced+Queries#AdvancedQueries-%7B%7B%24type%7D%7D PS. I think you need some sleep If you have more questions about data-types you might want to take it up on the list. It is more distracting to others here. | ||||||||||||||||
| Comment by Christoph Menge [ 23/Oct/10 ] | ||||||||||||||||
|
Scott, either I'm just too exhausted (it's 2am here), or there's a MAJOR bug then: >> NumberLong class that represents the stored 64bit signed values in the shell/js I just did this: ; ; storing these to MongoDB and fetching them with a query }); }); }); Don't let that JavaScript deficiencies crawl in... | ||||||||||||||||
| Comment by Scott Hernandez (Inactive) [ 22/Oct/10 ] | ||||||||||||||||
|
Nope, there is no storing 64bit values as string in the server. Some client/driver may do that but it would be wrong. There is a special NumberLong class that represents the stored 64bit signed values in the shell/js since it isn't natively supported. | ||||||||||||||||
| Comment by Christoph Menge [ 22/Oct/10 ] | ||||||||||||||||
|
Paul, Performance is mostly a question of precision requirements: right now I might have to pull all items from the database and do the arithmetic myself; that's definitely slower than a base-10 implementation on the server-side. And we might just find a difference of two cents | ||||||||||||||||
| Comment by Paul Harvey [ 16/Oct/10 ] | ||||||||||||||||
|
As discussed on IRC, while it would be nice, floats aren't designed for 'exact' representation of numbers (base-10, base-2 or otherwise). IEEE-754 gives a way to store floats but actually using them on hardware with an FPU that's hard-wired for base-2 floats is less than ideal. Additionally, ECMA-262 4th edition's suggestion of a 'use decimal' directive for base-10 floats was obviously dropped (no mention of it in 5th edition). Even if it weren't dropped, I'm not sure the major JS engine implementers are taking much notice of ECMA-262 roadmap anyway. So at first glance it seems unlikely that any the of the javascript engines mongodb is likely to work with will support base-10 floats any time soon, although I could be wrong. I don't know about others, but for best performance we depend on server-side js in mongo to deliver only absolutely relevant results back to clients, and it seems that a variable radix float representation in the DB would horribly break/complicate the JS side of things, unless you had some sort of global conf to set the float type for all floats that are stored and used in your entire mongo cluster. Mixing base-10 and base-2 floats in the same system, especially with a query language that does not even support base-10 floats let alone have any mechanism to support different types of floats simultaneously (much less perform an operation involving both types!) sounds like a massive headache Edit: I just found a reference to IBM's POWER6 architecture which apparently 'fully implements' IEEE 754-2008 (I assume that includes arbitrary radix arithmetic), so there you go - are there many mongo users on zSeries mainframes? | ||||||||||||||||
| Comment by Mikael Nousiainen [ 17/Sep/10 ] | ||||||||||||||||
|
+1 vote for this feature. I need this for representing prices, which need to be exact. And the natural counterpart data-type in the Java driver would be Java's BigDecimal. | ||||||||||||||||
| Comment by Christoph Menge [ 04/Aug/10 ] | ||||||||||||||||
|
I believe this is a major issue and it would be a big step forward for MongoDB if decimal support was implemented. However, I think the current description of this issue is somewhat misleading: Decimal is a floating point type of fixed size, thus not of 'arbitrary precision', even though some ruby documentations say so. We should be clear what we talk about here, exactly. I think there is little use for real arbitrary precision and from the foregoing discussion it seems people think about an IEEE floating point decimal here. The point in decimal is that they use a different base (namely ten instead of two), so simple values such as 0.1 can be represented exactly, which is not possible with binary floating point, see http://stackoverflow.com/questions/618535/what-is-the-difference-between-decimal-float-and-double-in-c for a discussion. According to Wikipedia, IEEE754-2008 specifies floating point data types, both in binary and decimal, all of which could be interesting for MongoDB (even the 64 bit decimal type), see http://en.wikipedia.org/wiki/IEEE_754-2008. Since this is standardized I expect most programming languages to have their decimal implementations based on it, so it will we widely available to MongoDB users. | ||||||||||||||||
| Comment by Rei Roldan [ 03/Aug/10 ] | ||||||||||||||||
|
This is quite a show stopper for financial type applications in .net land. | ||||||||||||||||
| Comment by Eliot Horowitz (Inactive) [ 12/Jul/10 ] | ||||||||||||||||
|
If you make them binary sortable then they are. | ||||||||||||||||
| Comment by Karl Seguin [ 12/Jul/10 ] | ||||||||||||||||
|
But you can't filter on it - which is pretty common. | ||||||||||||||||
| Comment by Eliot Horowitz (Inactive) [ 11/Jul/10 ] | ||||||||||||||||
|
You can always use a custom binary subtype. |