atavakoli / angular-join Goto Github PK

Allow the API to be used like this:

var left = [
  { x:1, y:1 },
  { x:2, y:2 },
  { x:3, y:3 }
];
var right = [
  { x:1, y:4 },
  { x:1, y:5 },
  { x:1, y:6 },
  { x:2, y:5 },
  { x:2, y:6 },
  { x:3, y:7 }
];

var result = Join
  .selectFrom(left)
  .hashJoin(right, function(e) { return e.x; }, function(e1, e2) {
    if (e1 && e2) {
      return { x:e1.x, y1:e1.y, y2:e2.y };
    }
  })
  .where(function(e) { return e.y1 < 3; })
  .hashGroupBy(function(e) { return e.y1; }, function(prev, e) {
    if (!prev) {
      return { y1:e.y1, y2Sum:e.y2 };
    } else {
      prev.y2Sum += e.y2;
      return prev;
    }
  })
  .having(function(e) { e.y2Sum > 10; })
  .orderBy(function(e1, e2) { return e1.y1 - e2.y1; })
  .limit(100)
  .execute();

If an empty array is passed into sortGroupBy or hashGroupBy, then just return an empty array.

There's technically nothing in the core logic that requires angular. This can be made into a node.js module with little modification.

The $timeout and $q services are used in the fluent API (#2), but q could be used for the node version.

This is for the fluent API being implemented in #2. For example, the selectFrom, (hash|merge)Join, and (hash|sort)GroupBy all accept an array as their 1st argument, which should be allowed to be another query generated by Join.*, before .execute() is called.

The query should not be resolved until .execute() is called on the final result.

The query should be copied & not simply referenced (i.e. if query1 is used as a parameter into query2, then changing query1 after it's been used should not affect the output of query2.execute()). If the actual array(s) that either query reference are changed before .execute() is called, that's a different story.

Anywhere where a comparator or hash function is accepted, also accept a string or array.

For hash functions ( e.g. in hashJoin and hashGroupBy):

• Strings:
  • Value: 'x'
  • Function: function(e) { return e['x']; }
• Arrays:
  • Value: ['x', 'y']
  • Function: function(e) { return JSON.stringify([e['x'], e['y']]); }

For comparator functions ( e.g. in mergeJoin and sortGroupBy):

• Strings:

  • Value: 'x'

  • Function:

    function(e1, e2) {
      if (typeof e1['x'].localeCompare == 'function') {
        return e1['x'].localeCompare(e2['x']);
      } else if (typeof e1['x'].diff == 'function') {
        return e1['x'].diff(e2['x']);
      } else {
        return e1['x'] - e2['x'];
      }
    }
    

• Arrays:

  • Value: ['x', 'y']

  • Function:

    function(e1, e2) {
      var result = 0;
      ['x', 'y'].some(function(prop) {
        if (typeof e1[prop].localeCompare == 'function') {
          result = e1[prop].localeCompare(e2[prop]);
        } else if (typeof e1[prop].diff == 'function') {
          result = e1[prop].diff(e2[prop]);
        } else {
          result = e1[prop] - e2[prop];
        }
    
        return (result !== 0);
      });
      return result;
    }
    

Also, anywhere a callback for select or map is accepted (including the optional one in selectFrom), accept a string or array:

• Strings:
  • Value: 'x'
  • Function: function(e) { var result = {}; result['x'] = e['x']; return result; }
• Arrays:

  • Value: ['x', 'y']

  • Function:

    function(e) {
      return ['x', 'y'].reduce(function(prev, prop) {
        prev[prop] = e[prop];
        return prev;
      }, {});
    }
    

There may be more performant ways to do the above (e.g. toString instead of JSON.stringify, or inspecting the 1st object(s) & guessing at the fastest strategy). The immediate goal is correctness/usability; optimization is for another issue.

karma can be used as the test-runner, with jasmine as the framework.

The current default for string comparison (when comparator is a string or array) is to use localeCompare, which is much slower than Unicode code point comparison, and may not be needed in all cases.

The default should be Unicode-based comparison (as is the precedent with Array.prototype.sort()), and locale-sensitive sorting should be optional.

When a new operation is added to a query, a new copy of the query should be created, rather than modifying the existing one. This is so that existing queries can be used as starting points to new queries, without worry that the existing query is modified before the new query is executed.