LoadByUniqueConstraint() fails for live server but passes for embedded.

[Jim Bolla]

Running #2032, I'm having an issue with LoadByUniqueConstraint() that works fine under embedded, but fails when connection to server running as a windows service. I have the following code to demo:

using System;
using System.IO;
using System.Linq;
 
using NUnit.Framework;
 
using Raven.Bundles.UniqueConstraints;
using Raven.Client;
using Raven.Client.Document;
using Raven.Client.Embedded;
using Raven.Client.UniqueConstraints;
 
namespace RavenTest
{
    [TestFixture]
    public class UniqueConstraintTests
    {
        [TestCase("localhost")]
        [TestCase("embedded")]
        public void TestUniqueConstraint(string storeType)
        {
            using (var store = GetStore(storeType))
            {
                store.RegisterListener(new UniqueConstraintsStoreListener());
                store.Initialize();
                RequireTrigger(store, typeof (UniqueConstraintsPutTrigger));
 
                const string raven = "http://www.ravendb.net/";
 
                using (var session = store.OpenSession())
                {
                    session.Store(new Application {Realm = new Uri(raven)});
                    session.SaveChanges();
                }
 
                using (var session = store.OpenSession())
                {
                    var app = session.LoadByUniqueConstraint<Application>(a => a.Realm, new Uri(raven));
                    Assert.That(app, Is.Not.Null);
                }
            }
        }
 
        public class Application
        {
            public string Id { get; set; }
 
            [UniqueConstraint]
            public Uri Realm { get; set; }
        }
 
        private static DocumentStoreBase GetStore(string storeType)
        {
            switch (storeType)
            {
                case "localhost":
                    return new DocumentStore
                           {
                               Url = "http://localhost:8080",
                               DefaultDatabase = "UniqueConstraintTests"
                           };
 
                case "embedded":
                    return new EmbeddableDocumentStore
                           {
                               RunInMemory = true,
                               Configuration =
                                   {
                                       PluginsDirectory = Path.GetDirectoryName(typeof (UniqueConstraintsPutTrigger).Assembly.Location)
                                   }
                           };
                default:
                    throw new NotImplementedException();
            }
        }
 
        private static void RequireTrigger(IDocumentStore store, Type triggerType)
        {
            var triggers = store.DatabaseCommands.GetStatistics().Triggers;
            var installedTriggerNames = triggers.Select(t => t.Name);
 
            if (!installedTriggerNames.Contains(triggerType.ToString()))
            {
                throw new Exception(string.Format(
                    "The required trigger '{0}' was not detected. Verify the bundle '{1}' been installed into the" +
                    " server's plugins directory.",
                    triggerType, Path.GetFileName(triggerType.Assembly.Location)));
            }
        }
    }
}

The embedded test case will pass, but the localhost test case will fail at the Assert. My localhost server is also running 3032.

[Jim Bolla]

I tried changing the Realm property to string, still fails. Then I removed the trailing slash, still fails. Then I removed the remaining slashes, still fails. Then I removed the colon, leaving "httpwww.ravendb.net" as the realm, and the test passes. I put a slash back in the middle, fails. Something about the special characters is messing it up.

[Chris Marisic]

I think i vaguely recall something about trailing /s on urls causing issues with searches.

[Jim Bolla]

I'm guessing it's related to the url encoding issue that was discussed a couple weeks ago.

[Oren Eini (Ayende Rahien)]

Jim,

I found & fixed the problem. But this means another change to the way those sort of fields will behave.

Since they didn't work before, I don't think it is a big problem.

Fix will be in the next build.

[Jim Bolla]

Will that require rebuilding those documents or will the existing documents work as is?

[Oren Eini (Ayende Rahien)]

No, you'll need to rebuilt it.