You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Paul Pak <pp...@yellowseo.com> on 2011/01/09 17:07:01 UTC
re: can't create a jira ticket for cassandra
Hi,
I tried to create a JIRA ticket for Cassandra and got the following
error on submission.
java.lang.NumberFormatException: For input string: ""
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Long.parseLong(Long.java:431)
at java.lang.Long.<init>(Long.java:678)
at
com.atlassian.jira.issue.fields.AbstractVersionsSystemField.getRelevantParams(AbstractVersionsSystemField.java:193)
at
com.atlassian.jira.issue.fields.AbstractOrderableField.populateFromParams(AbstractOrderableField.java:173)
at
com.atlassian.jira.web.action.issue.IssueCreationHelperBeanImpl.validateCreateIssueFields(IssueCreationHelperBeanImpl.java:74)
at
com.atlassian.jira.bc.issue.DefaultIssueService.validateAndCreateIssueFromFields(DefaultIssueService.java:551)
at
com.atlassian.jira.bc.issue.DefaultIssueService.validateCreate(DefaultIssueService.java:522)
at
com.atlassian.jira.bc.issue.DefaultIssueService.validateCreate(DefaultIssueService.java:114)
at
com.atlassian.jira.web.action.issue.CreateIssueDetails.doValidation(CreateIssueDetails.java:56)
at webwork.action.ActionSupport.validate(ActionSupport.java:391)
at webwork.action.ActionSupport.execute(ActionSupport.java:162)
Then I tried to notify the jira administrators/support and pasted the
content and I got the same error. lol
Anyone have a clue as to how I can get this ticket submitted? Thanks,
Paul
===========================================
Need to return start keys for every 100 results for efficient paging
retrieval
===========================================
If you have a result set with thousands of results, like an inbox,
there is no way to efficiently handle the retrieval of pages
i.e. <- [previous] 1 2 3 4 5 6 7 8 9 10 [next] ->
except by creating additional data structures on a materialized
view. But that means you can only get paged views on materialized
views. If you were to add constraints, all the paging functionality no
longer works. This is a basic functionality that many, many
applications need. Essentially it means that we can only perform the
most basic queries in Cassandra and secondary indexes and super columns
are near useless. Super Columns are useless for doing complex queries
because of a lack of secondary indexes and the fact that it needs to
deserialize the entire row to work with it. Regular CF's are no good
too for queries with constraints because the paging no longer works
since there is no materialized view. There is no way to get the 800th
record in a result set without getting ALL the data up to the 800th
record. Cassandra desperately needs an efficient
capability to return a result set by specifying a start_column by record
number, not key. Or alternatively, we can return the start keys for
every 100 results to the client so that they can use those start keys
for doing a query.
Re: can't create a jira ticket for cassandra
Posted by Jeremy Hanna <je...@gmail.com>.
Hmmm, I've never seen that when creating Jira tickets. You might try to just fill out the basic info first - Summary/Description. Then go in and edit the ticket that was created - that way you can at least create the ticket and bypass whatever error you're seeing. Weird though.
On Jan 9, 2011, at 10:07 AM, Paul Pak wrote:
> Hi,
>
> I tried to create a JIRA ticket for Cassandra and got the following
> error on submission.
>
> java.lang.NumberFormatException: For input string: ""
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
> at java.lang.Long.parseLong(Long.java:431)
> at java.lang.Long.<init>(Long.java:678)
> at
> com.atlassian.jira.issue.fields.AbstractVersionsSystemField.getRelevantParams(AbstractVersionsSystemField.java:193)
> at
> com.atlassian.jira.issue.fields.AbstractOrderableField.populateFromParams(AbstractOrderableField.java:173)
> at
> com.atlassian.jira.web.action.issue.IssueCreationHelperBeanImpl.validateCreateIssueFields(IssueCreationHelperBeanImpl.java:74)
> at
> com.atlassian.jira.bc.issue.DefaultIssueService.validateAndCreateIssueFromFields(DefaultIssueService.java:551)
> at
> com.atlassian.jira.bc.issue.DefaultIssueService.validateCreate(DefaultIssueService.java:522)
> at
> com.atlassian.jira.bc.issue.DefaultIssueService.validateCreate(DefaultIssueService.java:114)
> at
> com.atlassian.jira.web.action.issue.CreateIssueDetails.doValidation(CreateIssueDetails.java:56)
> at webwork.action.ActionSupport.validate(ActionSupport.java:391)
> at webwork.action.ActionSupport.execute(ActionSupport.java:162)
>
> Then I tried to notify the jira administrators/support and pasted the
> content and I got the same error. lol
>
> Anyone have a clue as to how I can get this ticket submitted? Thanks,
> Paul
>
> ===========================================
> Need to return start keys for every 100 results for efficient paging
> retrieval
> ===========================================
> If you have a result set with thousands of results, like an inbox,
> there is no way to efficiently handle the retrieval of pages
>
> i.e. <- [previous] 1 2 3 4 5 6 7 8 9 10 [next] ->
>
> except by creating additional data structures on a materialized
> view. But that means you can only get paged views on materialized
> views. If you were to add constraints, all the paging functionality no
> longer works. This is a basic functionality that many, many
> applications need. Essentially it means that we can only perform the
> most basic queries in Cassandra and secondary indexes and super columns
> are near useless. Super Columns are useless for doing complex queries
> because of a lack of secondary indexes and the fact that it needs to
> deserialize the entire row to work with it. Regular CF's are no good
> too for queries with constraints because the paging no longer works
> since there is no materialized view. There is no way to get the 800th
> record in a result set without getting ALL the data up to the 800th
> record. Cassandra desperately needs an efficient
> capability to return a result set by specifying a start_column by record
> number, not key. Or alternatively, we can return the start keys for
> every 100 results to the client so that they can use those start keys
> for doing a query.