WQL Help, options rule

I think I get what is wrong.  I'm still not sure I'm using apend right, I'm meaning to test is the two parts of the "refer_to" point to the same thing, but I'm really searching for this card's +field card as a reference, and I want the comparison to what it refers to.  Is it as simple as wrapping that 2nd arg in a referes_to?

---

I'm wondering if a wagneering feature to see something about how the query is interpreted. WQL is already a bit developer, but we don't have the wagneering UX that we would want to be able to hide it from them. In the meantime, some developer level debugging might be helpful.

---

Oh, maybe I need 'in' with refers_to. Trying again.

---

1. refer_to requires a card definition, which can be a string or a hash but never an array.

2. append only ever makes sense in the root card definition, because it's a post-processing action -- takes place after all SQL

3. in the context of search card A+B, A = self. Legacy weirdness. We're fixing that.

 

you're looking for something like

{

"type":"Scope",

"right_plus": [

"field",

{

"refer_to": { "type":"Field", "referred_to_by":"_+field" }

}

]

}

 

---

Thanks. It's better than the one it replaces, but it doesn't return any results. I'm pretty sure I have data that will use the rule on the two Intention cards I already created. There is at lease one Scope with the Field used in each of the Intentions. Maybe I can tweak it to work.

 

How do you debug complex queries? Or do you just have enough WQL know how to figure them all out?

---

I thought that context issue was merged and released? Only merged? Or not yet fully fixed?

---

FYI, if this wasn't clear. Most of these are Pointer cards, by which I mean that I+scope is a Pointer card to a Scope card.  So, the search is to get the Scopes that have the same +field value (a Pointer to one thing again) as the base card (the Intention in the examples.

You may have some advice for me on modeling ORM relationships with cards. Should I make I+scope be the Scope card, using just the + relationship as the has_one?

---

not merged: https://github.com/wagn/wagn/pulls (last one)

 

WQL debugging is pretty easy: you do it from the inside out.Try:

 

{ "type":"Field", "referred_to_by":"_+field" }

 

you should get the fields referred to by (Intention)+field. When that works try:

 

{ "refer_to": { "type":"Field", "referred_to_by":"_+field" } }

 

you should get all the cards (presumably mostly plus cards) that refer to that field. Every hash must be a complete WQL query unto itself. This is kind of what makes WQL awesome ;)

 

-e

 

---

Right, I remember seeing that debugging advice before.

BTW, that _self, _left thing is fixed. That's the problem with your suggestions and I at least partly believed you on that.

---

So, your suggested query was exactly right except for the _/_left thing. Then I had created both Scale and Scope and I had some of each type.

---

One more QQ on this discussion. How best to match _self to reject if from the results? {"not":"_"} added to the conditions? {"not":{"name":"_self"}} ?

---

Do we have a library of common WQL patterns for more complex things?

This one is a bit special, but there is probably a pattern in the two types with a common attribute (tag) that scopes various searches to a value of that attribute (Pointer attribute as here or otherwise probably).

The one I just figured out that is maybe more common is the parent/child pattern. In my case, the +parent of the type is a Pointer to a card of the same type, and +children is a virtual card for all Cards of that type with this card as its parent.

{"right_plus":["parent", {"referred_to_by":{"right_plus":["parent",{"refer_to":"_left"}]}} ]}

I guess it is independent of type, so could be *right rather that *type_plus_right as I did initially.

---

---

the _self / _left thing is not yet fixed, I promise. Above is an example, below is the code.

 

query[:context] ||= (cardname.junction? ? cardname.left_name : cardname)

 

Perhaps you're using A+B+C somehow?

 

"not":"_" should work just fine.

 

Nope, no common library yet.

---

Then the conclusion is the case of _self/_left that fixed my query isn't really the buggy case, so it uses the expected contextual reference? I think you understand the WQL better than me, but in your example, the "_+field" in the "referred_to_by" clause is wrong. It works with _left. The why part is pretty opaque for me. I will take a look and the PR and see if that helps my understanding.

As for the common library, what do you thing about getting that started by creating a Cardtype and template for them? Then we could start accumulating them even if they aren't organized at all? It might also be a better place for discussing and debugging the WQL for particular cases in the discussion card.

 

---

One more QQ. Does WQL have a way to reference the Nth item of a pointer card?

I ask because I'm thinking of representing something like an Enumerator as a Pointer card. The pattern I want is something like (T+R) set Field+scale is a Pointer to a Scale card, and when say the set Intention+scale is a Select from (Field instance)+scale, using the Field card at (Intention instance)+field.

Actually now that I lay that much out, I might not need any Nth item selector for this. I might want to know the 'rank' of an Intention's scale setting within the Scale card from the Field plus card, or order results by that rank.

My not so QQ is whether this is a good idea, or not the Wagn/Decko way?

I'm trying to implement as much of the structure for something like what I understood FlowPlace to be designed for.

I always thought that applications like this that are more about innovation in social process/architecture are a sweet spot for Wagn. Essentially, such applications want general Wiki and discussion supports, but they need Wagn's ability to structure data like an application. Working within the scope of advanced Wagneering, applications can be produced that require a bit more from the users to fully interact with the application. We've characterized users who maintain content as "editors", but sometimes we have to ask them to interact a bit with Wagn structure (wagneering).

This is a pattern in Wiki communities, editing at some point blends into the technology of the platform. We want to produce the finished applications for readers and users, and non-technical access for editors, but the working prototype falls short. It is ok to have a community of 'power users' who are capable of 'blugeoning the data' (to use Mark Dilly's term for it) before the app is usable by the masses. They can help maintain a reader/user environment where most of the bad parts are hidden by an active support community who can restructure data with the general tools.