NOODB: Constraints

The constraint feature is working. It’s not done, but happy-path is good to go.

This clip demonstrates 4 things.

  1. Just save an object without any constraints. We’ve done that a million times before, so nothing enlightening there.
  2. Create a constraint, then save an object that fails the constraint. It goes boom.
  3. Create a constraint, then save an object that passes it. No boom.
  4. Extend #3 to re-prove #2. Another failure.

Good stuff. At least in my opinion. But then, I suppose I’m biased.

If anyone is reading this, I’d love to get some feedback.

        [TestMethod]
        public void DemoConstraint()
        {
            TestUtility.DeleteTestData();
            try
            {
                IClient client = new Client(new Server(TestUtility.DefaultUnityContainer));

                MovieReview2 review = new MovieReview2 { Author = "Jay", Comments = "yay!", Id=4 };
                Author author = new Author { Name = "Jay", Title = "Whatever" };

                // ----------------------------------------------------------------------
                // no constraint. works just fine.
                // ----------------------------------------------------------------------
                client.RegisterType(typeof(MovieReview2));
                client.Save(review);

                // ----------------------------------------------------------------------
                // add the constraint without the constraint data. it'll fail.
                // ----------------------------------------------------------------------
                TestUtility.DeleteTestData();
                client.RegisterType(typeof(MovieReview2));
                client.RegisterType(typeof(Author));

                // MovieReview2.Author is constrained by Author.Name. (We know .Name, because that's AUTHOR's key.)
                client.SetConstraint<MovieReview2, Author>("Author");
                try
                {
                    client.Save(review);
                    Assert.Fail("Should've failed.");
                }
                catch (Exception ex)
                {
                    // need a custom exception, and to elaborate on the message.
                    Assert.AreEqual("Property value violates the constraint.", ex.Message);
                }

                // ----------------------------------------------------------------------
                // now, create the constraint, an author, and a review that 
                // matches the constraint.
                // ----------------------------------------------------------------------
                client.RegisterType(typeof(MovieReview2));
                client.RegisterType(typeof(Author));

                // MovieReview2.Author is constrained by Author.Name. (We know .Name, because that's AUTHOR's key.)
                client.SetConstraint<MovieReview2, Author>("Author");

                // create the author, and the review will save.
                client.Save(author);
                client.Save(review);
                MovieReview2 reviewFromDb = client.GetObjects<MovieReview2>()[0];
                Assert.AreEqual("Jay", reviewFromDb.Author);

                // getting repetitive now. let's change the author and watch it fail 
                // because it fials the constraint.
                review.Author = "Santa";
                try
                {
                    client.Save(review);
                    Assert.Fail("Should've failed.");
                }
                catch (Exception ex)
                {
                    Assert.AreEqual("Property value violates the constraint.", ex.Message);
                }
            }
            finally
            {
                //TestUtility.DeleteTestData();
            }
        }

Advertisements

4 Responses to NOODB: Constraints

  1. Vadim says:

    Jay,

    I’m reading all your posts. I’m a little bit behind but I do read what you write.

    It’s much easier to give suggestions than actually to do something. Therefore, here are my suggestions:

    1. Even it’s very easy to read your test, I would prefer to break the test into multiple smaller tests.

    2. When you need to save the parent and the child objects you currently saving the child and then the parent:
    client.Save(author);
    client.Save(review);
    Which is fine and I would keep this format. May be you also would like to add another overload for Save. Something like this:
    client.Save(review, new Children[] { author });

    Otherwise, it looks very good.

  2. hamletcode says:

    Greetings

    RE: Saving the child then the parent
    In this demo, it’s demonstrating a constraint. You wouldn’t be able to save the REVIEW unless the AUTHOR was already saved. In reverse order, it would’ve thrown an exception when you save.

    As for the Children[] approach… Using that syntax, how would it know which property the children correspond to?

    The way this would work in NOODB is that you just create the MovieReview and the Author, put them together and it would save.

    client.Save(new MovieReview { Author = new Author {…}, Movie = new Movie {…})

    That will work today, as long as SaveIfNested=0. Right now, that rule is just on or off. It’s going to have to evolve to “If the object already exists, don’t save it. If it’s new, create it.”

    Going forward, I’ll use smaller unit tests. I was trying to use it to demonstrate full scenarios, but this example could be broken into 3 or 4 smaller scenarios. Thanks for the suggestion.

    I hope to get back to work on this over the weekend. I’ve been thinking about the query parser… I think I’m a week or two away from that. That’ll be something new.

  3. Vadim says:

    Of course I don’t know how save is implemented.

    If each type knows how to save it self, I thought that it possible to have something like this:

    foreach (ISavable child in Children)
    {
    child.Save();
    }

    parent.Save();

    In your case you use IClient.Save(object) and I have no clue how it’s implemented.

    It’s just a suggestion and if it makes no scenes, just ignore it.

  4. hamletcode says:

    I wouldn’t ignore a suggestion.

    I’m trying to stay away from required decorators, interfaces and base classes. I don’t want people to have to do anything special to use it; they don’t need to bind to NOODB. Later, there can be things to make life easier for them if they want to bind to NOODB, but they’d never have to. This suggestion would come into play at that time, but at this stage, everything is strictly POCO.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: