When utilizing classes with constructors, Linq queries are throwing an argument exception stating the RowSet columns length is not the same amount of parameters as the constructor (specific message for example: "Additional information: RowSet columns length is 5 but type TestCS25Driver.Issuer does not contain a constructor with the same amount of parameters"). I believe this should instead be set to determine whether the number of columns in the rowset equal the number of properties on the class instead of comparing with the number of parameters in the constructor.
To keep the sample code as simple as possible, I created an "Issuer" object with a constructor that accepts an external Id (i.e. stock issuer symbol) and a name as required parameters. The remaining three parameters are set by the constructor (id -> new guid, timestamps to current time):
The main program.cs simply creates a test keyspace, the Issuer schema, populates two stock issuers, and then the query to reproduce the error:
Windows 8.1 Update development laptop using Cassandra 2.1.3
I think the behaviour is expected, the exception thrown and the documentation are not clear about it.
When providing mapping definition via attributes, it requires a parameterless constructor. In your example, if you add the constructor:
It will work.
The driver also works if there isn't a parameterless constructor but it contains a constructor with the same amount of parameter as columns in the RowSet. This is useful for Anonymous types and Tuples support.
On the other hand, the documentation never specifies it, so we should add this. Also, the exception message should be something like
"RowSet columns length is X but type Y does not contain a constructor with the same amount of parameters. You should create a parameterless constructor for type Y."
Perhaps this would be better marked as a feature request then. As mentioned above, the check should be against the number of properties in the class and not the number of parameters in the constructor. This would allow the developer to set default values for certain columns, such as the CreatedTimeStamp column in the example provided.
Validating the amount of properties vs amount of columns could be a problem for some users, as they can use those properties for other purposes.
The real constraint is to have a parameterless constructor, I think it is a reasonable constraint for a mapping layer. In the parameterless constructor, you can set the default values.
In your example:
I sent the request to the docs team to include the need of a parameterless constructor in your classes.
I will close this one.