Pull request

Jul 16, 2012 at 7:23 AM


Do you have any news on the pull request I submitted? Feel free to refactor anything, but I just needed the datetime to be Java compatible.



Jul 17, 2012 at 1:56 AM

Thanks for pull request.

But there are some problem.

Timestamp of cassandra column is generated by TimeGenerator.GetUnixTime method. Timestamp should be microseconds because cassandra-cli also use microseconds.

To use milliseconds for column name or column value is a moot point. If we store bytes date serialized java Date class, then we should use java model. But now ticks data of DateTime is stored. It is longtype data. If DateTime is converted to unix time of milliseconds, data is rounded down in .NET. I think ticks data should be also used for column name and column value. In java, Can you make convert method like TicksToUnixtime?

Jul 23, 2012 at 9:11 AM


You were right about the column timestamps, it was my mistake, I fixed it in the latest patch.

For the column names/values I agree that we loose some precision by doing so, but it is the way other clients do it. For example, Datastax's OpsCenter cannot display our data in their explorer because we use a .Net specific format for datetime.

So I agree that your version adds precision, but it also looses compatibility with other non-Cassandraemon applications which can be a problem.

Is the precision gain worth loosing this compatibility?

Jul 24, 2012 at 5:50 PM

OK. I thought another idea.

Cassandraemon should have another date class, example Cassandraemon.Java.Date class.

// Cassandraemon.Java.Date outline
public class Date
    public DateTime Value { get; set; }

    public Date(DateTime value)
        Value = value;

And when this class call ToCassandraByte extension method, it return byteArray of milliseconds. So if we use this class for field of my own model class, it will store as bytearray of milliseconds. User is able to choice .net datetime or java date.

What do you think?

Jul 27, 2012 at 3:22 PM
Edited Jul 27, 2012 at 3:23 PM

I think that's a good solution, it might be better to have the default choice being the Java one though. For exemple, the Java one could be 

public class Date { }

And the more precise .Net specific version could be

public class PreciseDate { }

This way the user understands which one is the standard Cassandra date.

Anyway, both solutions fit me so you can pick the one you prefer. Do you want me to do it in my fork or are you doing it on the trunk?

Jul 31, 2012 at 11:39 PM

I might like my idea because PreciseDate overlap DateTime.

I want to implement this. If you can wait about one month, leave the matter to me.

Oct 4, 2012 at 6:50 AM

Hi there, it's been two months now and I wanted to know if you needed help.

If you give me more details on how you want to implement it, I can do it in a fork.

Oct 5, 2012 at 2:25 PM

Sorry, now I am busy. I will be able to implement this a little later.

I think that we must implement following.

- Add Cassandraemon.Java.Type.JavaDate class

- fix ByteArrayExtensions.cs, CassandraBinaryExtensions.cs, ObjectExtensions.cs for JavaDate

- fix MappingUtil.cs for JavaDate

- Add utility method for JavaDate to TimeGenerator.cs

If you have any comments, please let me know.

And if you can't wait, implement this in a fork.