Evan Schmidt

Hi Evan,

Looking through user cards I realized you'd signed up at a busy time and I never said "hello". Impressed by all the overlap in your interests and ours. Would love to know if Wagn can help you with any of your work.

  --Ethan McCutchen.....Wed Mar 03 14:54:23 -0800 2010

Some potential. Are there plans to provide more traditional query functionality (card counts for instance)?

Evan

  --Evan Schmidt (Not signed in).....Wed Mar 03 18:26:39 -0800 2010

More time using WAGN would probably help me answer some questions as well. LTM.

  --Evan Schmidt (Not signed in).....Wed Mar 03 18:28:32 -0800 2010

Yes, card counts are coming soon, as are "calculations", in which you'll be able to perform operations on numbers returned by a query.

For what it's worth (which ain't much to a user), counts have been implemented on a low level for some time -- it's just a matter of making them convenient to display.

  --Ethan McCutchen.....Wed Mar 03 19:35:00 -0800 2010

Not being as intimate with WAGN I wonder if WQL syntax can be extended to include more SQL operators (function regardless of form) with accompanying cards to accomodate result sets.

  --Evan Schmidt.....Wed Mar 03 20:02:10 -0800 2010

Well this is a great question. Our roadmap in this area has a lot of fuzzy spots on it, but here are some of the considerations:

1. Context: WQL is used both by "Wagneers" (expert users who configure Wagn) in Search cards and by developers in code. As of yet, Wagneers cannot really make full use of all that Developers can do.

2. Functions: For example, Wagneers currently always expect WQL to return a list of cards, which is why on the display side Wagn can't yet handle things like counts (though you do see the count results in paging). So in order for users to be able to make more use of *functions* that apply to result lists like sums, averages, and counts, it needs to be able to treat a result more or less like simple content. Not a huge hurdle, but it's not there yet.

3. Operators: It may be simple to add a few more comparison operators, though my biggest pain in this area is that we can't compare, say, the name of one card with the content of another. That has come up a few times. But I may not be thinking of the same operators you are. Are there other operators you have in mind?

4. Post-processing. There are already a couple of WQL operators (append and prepend) that take effect after the SQL is processed. This was added so that WQL could return virtual cards. Since virtual cards are, by definition, not in the database, then for WQL to return them, it had to do something after the database stage. One thing to consider as we weigh in new possible operators is whether we want them to be able to take effect on virtual cards.

5. Combination. One thing we like about WQL is that we can do one query and then re-use it in so many ways. I'm interested in thinking of how we can keep the list of cards and the operation on the list of cards separate so that a single query can be reused. That approach is consistent with the DRY (don't repeat yourself) imperative, but it can lead to some performance hurdles.

6. Data Engine. Right now Wagn is basically a nonrelational model built on top of a relational engine (either mysql or postgres). We see Wagn eventually moving the direction of running on top of an engine better optimized for our kinds of structures and have some hesitation about tying WQL too closely to SQL lest that complicate the eventual translation. Probably not a huge limiting factor, but something we try to keep in mind.

  --Ethan McCutchen.....Fri Mar 05 08:42:22 -0800 2010