You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@usergrid.apache.org by GERey <gi...@git.apache.org> on 2016/05/06 23:30:43 UTC

[GitHub] usergrid pull request: Release class cast exception

GitHub user GERey opened a pull request:

    https://github.com/apache/usergrid/pull/517

    Release class cast exception

    Fix for class cast exceptions when migrating for notifications.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/GERey/usergrid ReleaseClassCastException

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/usergrid/pull/517.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #517
    
----
commit c46e1b6871516009edeb4ab1a35603850f3645d8
Author: George Reyes <gr...@apache.org>
Date:   2016-05-06T22:36:11Z

    Cherrypicking first of the changes to account for future possible instances of the class cast exception

commit 0f13650f500809b2d044568570dbf11f4a57f70c
Author: George Reyes <gr...@apache.org>
Date:   2016-05-05T16:29:03Z

    Added test and cleaned up imports that proves that the class cast issue will no longer occur.

----


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] usergrid pull request #517: Release class cast exception

Posted by asfgit <gi...@git.apache.org>.

Github user asfgit closed the pull request at:

    https://github.com/apache/usergrid/pull/517


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] usergrid pull request: Release class cast exception

Posted by michaelarusso <gi...@git.apache.org>.

Github user michaelarusso commented on the pull request:

    https://github.com/apache/usergrid/pull/517#issuecomment-217862115
  
    Could we just keep Long and handle the casting in the notifications service where it comes in from the API (to make sure the number is put in the properties map as long instead of int):
    
    org.apache.usergrid.services.notifications.NotificationsService#postCollection
    
    Seems cleaner if we just handle the case there rather than making the Entity definition to a generic 'Object' and doing explicit casting in multiple places.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] usergrid pull request: Release class cast exception

Posted by GERey <gi...@git.apache.org>.

Github user GERey commented on the pull request:

https://github.com/apache/usergrid/pull/517#issuecomment-217963801

Would totally agree if it wasn't for the following two issues:

1. People already have Integers in statistics. By not accounting for Integers we force everybody who had notification statistics to not have access without them doing a re-put of all afflicted data.

2. The endpoint you mentioned is also an issue, but not the one I tested against. My main concern was with a UUID PUT with the payload. If you check my test you can see it in more detail. It would skip the NotificationService#postCollection and instead go through org.apache.usergrid.services.AbstractCollectionService#putItemById.

The way I see it is that it is a bit ugly, but it stems from the fact that we have a field that is required to be Long but we don't explicitly enforce that on POST's or PUTs. The way we deal with this for regular entities is to useobject maps because then we can use any type based on what the user wants. Thats why I used objects above, but I can also agree that is really just a hack until we do the aforementioned checking for all of our expected types.

---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---