RE: [RavenDB] Problem with AbstractIndexCreationTask when usingFindIdentityProperty conventions

[Kijana Woodard]

Why?

---

From: Jonas Hedlind
Sent: ‎8/‎21/‎2014 6:44 AM
To: rav...@googlegroups.com
Subject: [RavenDB] Problem with AbstractIndexCreationTask when usingFindIdentityProperty conventions

I use lower case "id" as my document id convention in RavenDB (build 2910 and 2916)

var store = new DocumentStore

            {                                 

                Conventions =

                {

                    FindIdentityProperty = q => q.Name == "id"

                }

            };

Say I have an index on Tasks created using: ( BTW.. just for show, not actually using this index )

public class Task
{

    public string id { get; set; }

    public string Name { get; set; }

}

public class Task_Index : AbstractIndexCreationTask<Task, Task_Index.TaskIndexData>

    {

        public class TaskIndexData

        {  
            public string TaskId { get; set; }

            public string Name { get; set; }

        }

        public Task_Index()

        {

            Map = Tasks => from t in Tasks

                           select new TaskIndexData

                           {                               

                               TaskId = t.id,

                                                              Name = t.Name,                               

                           };

        }

    }

Looking in Raven studio the generated index looks something like this

docs.Tasks.Select(t => new {

    TaskID = t.id, //does not populate unless I use t.Id

    Name = t.Name

})

The TaskId property in the index is always null unless I manually change the index to use t.Id..

What am I missing here? The __document_id property is there but how do I use it from the Map/Reduce in AbstractIndexCreationTask?

Seems like AbstractIndexCreationTask should look at the documnt id convention and change the lower case "id" to "Id" in the generated index?..

--
You received this message because you are subscribed to the Google Groups "RavenDB - 2nd generation document database" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jonas Hedlind]

Look like you started a new thread here..

Why what? Why there is a problem: Because TaskId does not get set to the t.id value (the document id in this case)..

[Kijana Woodard]

Sorry about the thread thing. Phone.....Anyway.

Why would you want a lowercase "id"?

Seems strange. Not canonical c#. It's already causing you grief. 

What's the upside?

[Federico Lois]

I have to agree with Chris. After you realize that changing conventions setup you for a pain experience in the long run, you end up accepting them and find interesting side effects you can exploit.

For example: setting your ids in such a way that you encode important information in it allows you to then filter or accessing the objects directly. That is something you wouldn't realize if you use integer ids.

---

From: Chris Marisic
Sent: 8/21/2014 11:58
To: rav...@googlegroups.com
Subject: [RavenDB] Re: Problem with AbstractIndexCreationTask when usingFindIdentityProperty conventions

I'm pretty sure those conventions are merely client conventions. That the server has no knowledge of them and as you see it behaves in its standard fashion regarding the special treatment of "Id" and __document_id

Just stop fighting core conventions. You are just setting yourself up for pain. Just use Id and you won't regret it. Just like every person that uses int Id at some point in their system they come to regret their choice. Just because you can, doesn't mean you should.

[Jonas Hedlind]

Started out using id because the front end is using (assigning) lower case id as objectId. I could have still used Id when storing it in Raven but using the convention made it easy to change and it has not caused any problems up to this point... Sure it looks odd in c# but... 

[Chris Marisic]

I would have my middleware between the browser/client and server address this.

I would never allow my client to pollute my database.

[Jonas Hedlind]

 I did not see it as pollution :).. I was merely changing the name of the document Id and it was easy.. 

Mapping between the two in the middleware is probably a good choice too.. First project with Raven, we used SQL server at first, and it has been an interesting learning experience.. I am sure there is lots of "pollution" from the SQL world in our data.. Cleaning it up/ trying new ways of doing it as we go..  

[Kijana Woodard]

If using mvc, the model binder will sort it out. 

But then I never post the model directly from the client, unless it's low value CRUD sections of the app. Admin screens and what not.

On Thu, Aug 21, 2014 at 3:46 PM, Jonas Hedlind <jhed...@gmail.com> wrote:

 I did not see it as pollution :).. I was merely changing the name of the document Id and it was easy.. 

Mapping between the two in the middleware is probably a good choice too.. First project with Raven, we used SQL server at first, and it has been an interesting learning experience.. I am sure there is lots of "pollution" from the SQL world in our data.. Cleaning it up/ trying new ways of doing it as we go..  

--