"NULL_VALUE" causes index replication fail, bug?

[micro]

The code of IndexReplication handle the field null value as below

if (field == null )

parameter.Value = DBNull.Value;

however, I think the actual field value now becomes "NULL_VALUE" already which cause the handling above does not work.

I made change like this and it works fine

if (field == null || field.StringValue() == Constants.NullValue)

       parameter.Value = DBNull.Value;

I guess this is a bug.

Thanks

[Oren Eini (Ayende Rahien)]

Thanks, fixed in the next build 

[Oren Eini (Ayende Rahien)]

The fix is in here:

https://github.com/ayende/ravendb/blob/1.2/Bundles/Raven.Bundles.IndexReplication/IndexReplicationIndexUpdateTrigger.cs#L112 

And it is not in 960

On Mon, Jul 16, 2012 at 6:19 AM, Dalton <dalton.d...@gmail.com> wrote:

I'm still seeing this issue with many different types.  Can you confirm that it's fixed in build 960?

Specifically, I am getting various strings for null datetime, decimal, and int columns.  The strings are in the form "NULL_DATETIME", etc. 

Is there something specific that should be set up in the index or replication task itself?  The result sets specify the properties as the correct types...

[Dalton]

Thanks for the quick reply!

To satisfy a client need for sql reporting, we are replicating raven to a second instance, and then deploying many indexes onto that instance that replicate to SQL.

Essentially, this bug is a show stopper for that plan (and most likely any plan to replicate billable properties to SQL). Everything has to be loosely typed varchar to work around it. I could create a one off for our prod reporting replication, but that's not really ideal.

Any idea when it will get worked into a release build?

[Oren Eini (Ayende Rahien)]

We expect a release in a couple of months.

But note that this is a BUNDLE.

They are explicitly allowing you to create your own.

You can take the 1.2 version, compile that against 960 and run with it with zero issues.