I am running into a very hard to reproduce issue related to the LINQ provider. The class and table looks like the following:
[Table( "user" )]
public class User
{
[PartitionKey]
[Column( "user_id" )]
public string UserId { get; set; }
[Column( "certificate" )]
public string Certificate { get; set; }
[Column( "container" )]
public string Container { get; set; }
[Column( "password" )]
public string Password { get; set; }
[Column( "salt" )]
public string Salt { get; set; }
[Column( "update_timestamp" )]
public DateTimeOffset UpdateTimestamp { get; set; }
[Column( "user_attributes" )]
public Dictionary<string, string> UserAttributes { get; set; }
}
The query:
User user = Users.Where( x => x.UserId == userId.ToLower() ).Execute().FirstOrDefault();
The exception being thrown randomly is:
"ClassName": "System.InvalidCastException"
"Message": "Specified cast is not valid.",
"StackTraceString": " at Cassandra.Row.GetValue[T](Int32 index)\r\n at lambda_method(Closure , Row )\r\n at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()\r\n at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable`1 source)...
The problem it seems is that sometimes the column order doesn't match the row data and the cast fails - in this case it's trying to convert a DateTime to String. The table in Cassandra matches the definition above and the only wierd thing is that one of the columns (certificate) was added later after the table was created.
Like I said, this is very hard to reproduce and I have tons of code very similar to this that has no issues.
Are you using the C# driver v2.5.0 or the latest (v2.5.2)?
If you are using v2.5.0, could you update to the latest?
About the exception, could you post the complete stack trace?
Are you altering the table over again (like in a test environment) or it was altered in one point in time?
If the problem is the column order, as a workaround, specifying the columns in the select will avoid this issue:
But I'm really interested in find a way to reproduce and fix it.
1) I am using the 2.5.0 driver at the moment. I'll update and give it a shot and see if I can reproduce it.
2) I'll have to scrub it slightly, but I'll get you the rest of the stack as soon as I can. I will say everything further down the stack from there is just our web service code and .net libs.
3) The table was altered once a few weeks ago. I thought it might be a schema disagreement but all nodes report the same schema version. Also the application was restarted when the table was modified - so there wasn't a situation where the table change underneath the running application.
4) Specifying a select projection is exactly how I have fixed it in the few cases I have seen this. I have literally hundreds of queries throught the apps using this provider and it's only been in two cases that I have seen this behavior. Both cases where resolved with an explicit projection.
Do you have further info about this issue, on how to reproduce it?
Please feel free to reopen if this still occurs.