Okay, fair enough. Making BigDecimal deserialize faster would certainly be a good thing. I just don't want it to result in hard-to-diagnose errors if there's some kind of mismatch between client and server. If there's any difference then we should probably have a configuration property or an annotation on the remote service interface to turn laziness on.
On Fri, Jun 14, 2013 at 1:02 AM, David <david.no...@gmail.com> wrote: > Hi, > > Theoretically you are absolutely right. But practically is another > discussion, I am talking about thousands of lines that need to change just > for the GUI tier limitations. The GUI is just a fraction of the application > because the same Request/Response objects are used internally as well > (command pattern). Redesigning the entire application because of a > limitation of the GUI is nuts. But in the way we use BigInteger, I > understand your point of view. > > But the same problem is there with BigDecimal (somebody else filled an > issue so I did not bother to create a duplicate, it is marked as assume > stale). > > We show records with BigDecimal in Cell tables. Again RPC is slow here. > While the user will only click on certain records to make modifications. > Again I could refactor to wait with conversion to BigDecimal until the user > changes a value (to validate), but in this case BigDecimal was the right > data-type to use and it is not nice to have to redesign an application > because the RPC system of GWT has limitations. > > David > > > On Thu, Jun 13, 2013 at 10:20 PM, Brian Slesinsky <skybr...@google.com>wrote: > >> I agree; this seems like a workaround for one application that picked the >> wrong datatype. Maybe we should warn about BigDecimal being slow somewhere? >> If someone wants to do some performance tests of GWT-RPC serialization, >> publishing the results would be useful to the community. >> >> My recommendation in this case would be create a new class named "Id" or >> Key" that simply contains the BigDecimal, then modify the code to use it, >> then change the implementation to store the data in a string field instead. >> In the end you'll have more readable code. >> >> - Brian >> >> >> On Thu, Jun 13, 2013 at 12:03 PM, David <david.no...@gmail.com> wrote: >> >>> John, >>> >>> Well, if I don't have support for this patch then I better stop working >>> on it. I can understand that this is not seen as a priority for GWT. Worst >>> case I just replace the BigInteger/BigDecimal class in the project itself, >>> that is basically what I did right now. >>> >>> Oracle sequences can be configured as a range between -10ˆ-26 and 10ˆ27. >>> The Oracle JDBC drivers return >>> a BigInteger if you force it to the extremes. >>> >>> Changing the application is not feasible, that will be too much work, we >>> are talking about many thousands of dependencies in a huge codebase where >>> BigIntegers and BigDecimals are used - while handling this optimisation on >>> the RPC level can be done in just a few lines of code. >>> >>> In many cases we send large lists of objects that contain BigInteger, >>> BigDecimals but only a few will actually be interacted with. So in that >>> case we only need to convert the Strings to BigInteger (or BigDecimal) when >>> really needed. >>> >>> David >>> >>> On Thu, Jun 13, 2013 at 7:52 PM, John A. Tamplin <j...@jaet.org> wrote: >>> >>>> On Thu, Jun 13, 2013 at 3:14 AM, David <david.no...@gmail.com> wrote: >>>> >>>>> The lazy parsing would only happen during deserialisation in the >>>>> client. I think it is safe to assume that a BigInteger created through >>>>> toString on the server will not result in a parse exception in the client >>>>> code - or are there known incompatibilities ? >>>>> >>>>> I don't want that the regular constructor of BigInteger( String ) or >>>>> BigInteger( String, int) would behave differently than before. Not even in >>>>> the client when those BigInts are created in the client. That's why I was >>>>> asking about the possibility to have different serialisers on client and >>>>> server side. >>>>> >>>>> As the why, well currently the custom field serializer converts the >>>>> BigInteger to a String, the client side needs to parse the string and >>>>> convert it to an int array, which involves multiple substring, >>>>> Integer.parseInt and multiply and add operations. Somehow IE8 has a >>>>> problem >>>>> with this. IE9 and other browsers are more efficient, but still that is a >>>>> lot of CPU operations that can be avoided in my use case. >>>>> >>>>> In my particular use case they used BigInteger to represent a key in >>>>> the database (oracle uses sequence numbers that are bigger than what can >>>>> be >>>>> represented with long). That might have not been the best idea, but those >>>>> decisions have been made a long time ago, when I was not around. On the >>>>> server side there is a usage of equals and compareTo happening, which >>>>> would >>>>> be hard to implement without a BigInteger, so there is logic in the >>>>> choice. >>>>> They obviously don't want to have an extra layer of objects to avoid the >>>>> BigInteger in the GWT client since a lot of code is independent of client >>>>> or server, this would hinder code sharing between the tiers. >>>>> >>>>> On the client side these id's are only send forth and back between >>>>> client and server, no operation is ever performed, so making the custom >>>>> field serialiser and the BigInteger cooperate gives a big performance >>>>> improvement. They only operation needed on the client-side is equals, >>>>> which can also be optimized to do a String comparison when bother have not >>>>> been parsed after RPC. >>>>> >>>> >>>> I'm beginning to think such a change does not belong in GWT. In your >>>> example, wouldn't you be better served by only sending strings to the >>>> client rather than BigDecimals, if they client never does anything with >>>> them but send them back? I think it is going to be pretty rare in normal >>>> situations that you instantiate a BigDecimal but never actually use it in >>>> the client, so it seems the special-case hack for your use-case should be >>>> performed in your code instead. >>>> >>>> Too often people want to send things to the client that really don't >>>> belong there, and that includes particular representations of it. I know >>>> DTOs are extra work over just shipping your regular objects over the wire >>>> and GWT RPC makes that easy, but in many cases it is the wrong thing to do. >>>> Think about if you were building a proto for the communication -- would >>>> you send the data in the current form? If not, you shouldn't be sending it >>>> that way via RPC just because it is easy to do so. >>>> >>>> BTW, I thought Oracle sequence numbers did fit in long (aren't they >>>> int64?) -- at least all the JDBC code I see for manipulating them stores >>>> them in a Java long. >>>> >>>> -- >>>> John A. Tamplin >>>> >>>> -- >>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "GWT Contributors" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to >>>> google-web-toolkit-contributors+unsubscr...@googlegroups.com. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>>> >>>> >>> >>> -- >>> http://groups.google.com/group/Google-Web-Toolkit-Contributors >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "GWT Contributors" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com >>> . >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> >> -- >> http://groups.google.com/group/Google-Web-Toolkit-Contributors >> --- >> You received this message because you are subscribed to the Google Groups >> "GWT Contributors" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > --- > You received this message because you are subscribed to the Google Groups > "GWT Contributors" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
