on_change if's with nested properties

[ephopper]

given a document:

{
	"_id": "foo_doc1",
	"_rev": "1-xxxxxxxxxx",
	"foo": {
		"bar": {
			"baz": true
		}
	}
}

I can create an on_change doc that has:

"if": {
	"_id": "^foo",
	"_deleted": "undefined"
}

these will work fine. However if I try:

"if": {
	"foo": {
		"bar": {
			"baz": true
		}
	}
}

this doesn't seem to work.

are the if's only meant to work against the top-level properties of the documents?

[redgeoff]

Yes, the conditional logic only works against the top level. I can think of two possible enhancements for this:

1. Enhance https://github.com/redgeoff/spiegel/blob/eb31e148e92e3b62546e257308180f197ee798c6/src/on-changes.js#L210 to use recursion to support nested properties
2. Use https://github.com/crcn/sift.js so that we can support a whole host of different matching options. This would be cool, but it would break existing usage of Spiegel as the sift syntax is different than what is currently used in the on_change docs. However, we could prevent breaking existing usage by introducing a new where attribute that uses sift while simulatenously continuing to support the old if attribute.

Interested in implementing either of these?

[ephopper]

Gotcha. Yeah, I actually found that spot in the code but wasn't sure if I was missing something else. looking at sift makes me wonder if it wouldn't be possible to use mango selectors in the on_change docs somehow also. I'm not exactly sure how pouch deals with them off-hand, but I've been using mango selectors in my pouch change listeners and they work fine. I think for what I'm doing now though, I'll see about filtering the docs in the api called by the on_change doc. If I can find some free time, I'll take a look at what it would take to implement one of your above suggestions.

Thanks!

[redgeoff]

Using mango selectors would be a cool idea, but the current design takes a single _changes feed per database and then checks all on_change docs. In order to support mango selectors you'd need a feed per on_change and this would definitely increase the complexity of the change-listeners. I don't think that adding this complexity now is worth the trouble and it could actually lead to a lot of latency.

I still think using sift would be the cleanest enhancement for now.

[ephopper]

Good point. It seems that avoiding unneeded complexity and latency would be a good idea.

I'll have to keep my work around simple for the now given lack of time, but if I can I'll take a deeper look into sift.

Thanks!