vayacondios-client 0.3.1 → 0.3.2
Sign up to get free protection for your applications and to get access to all the features.
- data/Gemfile +2 -0
- data/features/events.feature +142 -2
- data/features/stashes.feature +106 -5
- data/lib/vayacondios.rb +1 -1
- metadata +4 -4
data/Gemfile
CHANGED
@@ -2,6 +2,8 @@ source 'https://rubygems.org'
|
|
2
2
|
|
3
3
|
# em-mongo is too loose with its dependencies; 2.0.0 bson breaks vcd
|
4
4
|
gem 'bson', '1.9.2'
|
5
|
+
# cookiejar 0.3.1 has busted file permissions WTF
|
6
|
+
gem 'cookiejar', '0.3.0'
|
5
7
|
|
6
8
|
gemspec name: 'vayacondios-server'
|
7
9
|
gemspec name: 'vayacondios-client'
|
data/features/events.feature
CHANGED
@@ -86,6 +86,146 @@ Feature: Events
|
|
86
86
|
]
|
87
87
|
"""
|
88
88
|
|
89
|
+
Scenario: Retrieving Existing Events with a Limit Query
|
90
|
+
Given the following Event exists under topic "topic" in the database:
|
91
|
+
"""
|
92
|
+
{
|
93
|
+
"_id": "id1",
|
94
|
+
"_t": "2012-02-13T12:34:42.452Z",
|
95
|
+
"_d": {
|
96
|
+
"alignment": "good"
|
97
|
+
}
|
98
|
+
}
|
99
|
+
"""
|
100
|
+
And the following Event exists under topic "topic" in the database:
|
101
|
+
"""
|
102
|
+
{
|
103
|
+
"_id": "id2",
|
104
|
+
"_t": "2012-02-13T12:34:42.452Z",
|
105
|
+
"_d": {
|
106
|
+
"alignment": "evil"
|
107
|
+
}
|
108
|
+
}
|
109
|
+
"""
|
110
|
+
When the client sends a GET request to "/v3/organization/events/topic" with the following body:
|
111
|
+
"""
|
112
|
+
{
|
113
|
+
"sort": "alignment",
|
114
|
+
"order": "desc",
|
115
|
+
"limit": 1
|
116
|
+
}
|
117
|
+
"""
|
118
|
+
Then the response status should be 200
|
119
|
+
And the response body should be:
|
120
|
+
"""
|
121
|
+
[
|
122
|
+
{
|
123
|
+
"id": "id1",
|
124
|
+
"time": "2012-02-13T12:34:42.452Z",
|
125
|
+
"alignment": "good"
|
126
|
+
}
|
127
|
+
]
|
128
|
+
"""
|
129
|
+
|
130
|
+
Scenario: Retrieving Existing Events with a Sort Query
|
131
|
+
Given the following Event exists under topic "topic" in the database:
|
132
|
+
"""
|
133
|
+
{
|
134
|
+
"_id": "id1",
|
135
|
+
"_t": "2012-02-13T12:34:43.452Z",
|
136
|
+
"_d": {
|
137
|
+
"alignment": "good"
|
138
|
+
}
|
139
|
+
}
|
140
|
+
"""
|
141
|
+
And the following Event exists under topic "topic" in the database:
|
142
|
+
"""
|
143
|
+
{
|
144
|
+
"_id": "id2",
|
145
|
+
"_t": "2012-02-13T12:34:42.452Z",
|
146
|
+
"_d": {
|
147
|
+
"alignment": "neutral"
|
148
|
+
}
|
149
|
+
}
|
150
|
+
"""
|
151
|
+
And the following Event exists under topic "topic" in the database:
|
152
|
+
"""
|
153
|
+
{
|
154
|
+
"_id": "id3",
|
155
|
+
"_t": "2012-02-13T12:34:45.452Z",
|
156
|
+
"_d": {
|
157
|
+
"alignment": "evil"
|
158
|
+
}
|
159
|
+
}
|
160
|
+
"""
|
161
|
+
When the client sends a GET request to "/v3/organization/events/topic" with the following body:
|
162
|
+
"""
|
163
|
+
{
|
164
|
+
"sort": "alignment",
|
165
|
+
"order": "asc"
|
166
|
+
}
|
167
|
+
"""
|
168
|
+
Then the response status should be 200
|
169
|
+
And the response body should be:
|
170
|
+
"""
|
171
|
+
[
|
172
|
+
{
|
173
|
+
"id": "id3",
|
174
|
+
"time": "2012-02-13T12:34:45.452Z",
|
175
|
+
"alignment": "evil"
|
176
|
+
},
|
177
|
+
{
|
178
|
+
"id": "id1",
|
179
|
+
"time": "2012-02-13T12:34:43.452Z",
|
180
|
+
"alignment": "good"
|
181
|
+
},
|
182
|
+
{
|
183
|
+
"id": "id2",
|
184
|
+
"time": "2012-02-13T12:34:42.452Z",
|
185
|
+
"alignment": "neutral"
|
186
|
+
}
|
187
|
+
]
|
188
|
+
"""
|
189
|
+
|
190
|
+
Scenario: Retrieving Existing Events with a Fields Query
|
191
|
+
Given the following Event exists under topic "topic" in the database:
|
192
|
+
"""
|
193
|
+
{
|
194
|
+
"_id": "id1",
|
195
|
+
"_t": "2012-02-13T12:34:42.452Z",
|
196
|
+
"_d": {
|
197
|
+
"alignment": "good"
|
198
|
+
}
|
199
|
+
}
|
200
|
+
"""
|
201
|
+
And the following Event exists under topic "topic" in the database:
|
202
|
+
"""
|
203
|
+
{
|
204
|
+
"_id": "id2",
|
205
|
+
"_t": "2012-02-13T12:34:42.452Z",
|
206
|
+
"_d": {
|
207
|
+
"alignment": "evil"
|
208
|
+
}
|
209
|
+
}
|
210
|
+
"""
|
211
|
+
When the client sends a GET request to "/v3/organization/events/topic" with the following body:
|
212
|
+
"""
|
213
|
+
{
|
214
|
+
"alignment": "good",
|
215
|
+
"fields": ["alignment", "id"]
|
216
|
+
}
|
217
|
+
"""
|
218
|
+
Then the response status should be 200
|
219
|
+
And the response body should be:
|
220
|
+
"""
|
221
|
+
[
|
222
|
+
{
|
223
|
+
"id": "id1",
|
224
|
+
"alignment": "good"
|
225
|
+
}
|
226
|
+
]
|
227
|
+
"""
|
228
|
+
|
89
229
|
Scenario: Creating Events
|
90
230
|
Given there are no Events under topic "topic" in the database
|
91
231
|
When the client sends a POST request to "/v3/organization/events/topic" with no body
|
@@ -136,7 +276,7 @@ Feature: Events
|
|
136
276
|
}
|
137
277
|
"""
|
138
278
|
And there are no Events under topic "topic" in the database
|
139
|
-
|
279
|
+
|
140
280
|
Scenario: Deleting Events with a Time Query
|
141
281
|
Given the following Event exists under topic "topic" in the database:
|
142
282
|
"""
|
@@ -157,7 +297,7 @@ Feature: Events
|
|
157
297
|
When the client sends a DELETE request to "/v3/organization/events/topic" with the following body:
|
158
298
|
"""
|
159
299
|
{
|
160
|
-
"after": "2012-01-01T00:00:00.000Z"
|
300
|
+
"after": "2012-01-01T00:00:00.000Z"
|
161
301
|
}
|
162
302
|
"""
|
163
303
|
Then the response status should be 200
|
data/features/stashes.feature
CHANGED
@@ -49,21 +49,30 @@ Feature: Stashes
|
|
49
49
|
"""
|
50
50
|
{
|
51
51
|
"_id": "topic",
|
52
|
-
"root": {
|
52
|
+
"root": {
|
53
53
|
"b": 1
|
54
54
|
}
|
55
55
|
}
|
56
56
|
"""
|
57
|
+
And the following Stash exists in the database:
|
58
|
+
"""
|
59
|
+
{
|
60
|
+
"_id": "topic",
|
61
|
+
"root": {
|
62
|
+
"b": 5
|
63
|
+
}
|
64
|
+
}
|
65
|
+
"""
|
57
66
|
When the client sends a GET request to "/v3/organization/stashes" with the following body:
|
58
67
|
"""
|
59
|
-
{
|
60
|
-
"root.b": 1
|
68
|
+
{
|
69
|
+
"root.b": 1
|
61
70
|
}
|
62
71
|
"""
|
63
72
|
Then the response status should be 200
|
64
73
|
And the response body should be:
|
65
74
|
"""
|
66
|
-
[
|
75
|
+
[
|
67
76
|
{
|
68
77
|
"topic": "topic",
|
69
78
|
"root": {
|
@@ -88,7 +97,7 @@ Feature: Stashes
|
|
88
97
|
"""
|
89
98
|
When the client sends a GET request to "/v3/organization/stashes" with the following body:
|
90
99
|
"""
|
91
|
-
{
|
100
|
+
{
|
92
101
|
"root.b": 1,
|
93
102
|
"fields": ["root.a"]
|
94
103
|
}
|
@@ -108,6 +117,98 @@ Feature: Stashes
|
|
108
117
|
]
|
109
118
|
"""
|
110
119
|
|
120
|
+
Scenario: Retrieving Stashes using Sorting
|
121
|
+
Given the following Stash exists in the database:
|
122
|
+
"""
|
123
|
+
{
|
124
|
+
"_id": "topic1",
|
125
|
+
"root": {
|
126
|
+
"a": {
|
127
|
+
"foo": 3
|
128
|
+
},
|
129
|
+
"b": 1
|
130
|
+
}
|
131
|
+
}
|
132
|
+
"""
|
133
|
+
And the following Stash exists in the database:
|
134
|
+
"""
|
135
|
+
{
|
136
|
+
"_id": "topic2",
|
137
|
+
"root": {
|
138
|
+
"a": {
|
139
|
+
"foo": 2
|
140
|
+
},
|
141
|
+
"b": 1
|
142
|
+
}
|
143
|
+
}
|
144
|
+
"""
|
145
|
+
When the client sends a GET request to "/v3/organization/stashes" with the following body:
|
146
|
+
"""
|
147
|
+
{
|
148
|
+
"root.b": 1,
|
149
|
+
"sort": "root.a.foo",
|
150
|
+
"order": "asc"
|
151
|
+
}
|
152
|
+
"""
|
153
|
+
Then the response status should be 200
|
154
|
+
And the response body should be:
|
155
|
+
"""
|
156
|
+
[
|
157
|
+
{
|
158
|
+
"topic": "topic2",
|
159
|
+
"root": {
|
160
|
+
"a": {
|
161
|
+
"foo": 2
|
162
|
+
},
|
163
|
+
"b": 1
|
164
|
+
}
|
165
|
+
},
|
166
|
+
{
|
167
|
+
"topic": "topic1",
|
168
|
+
"root": {
|
169
|
+
"a": {
|
170
|
+
"foo": 3
|
171
|
+
},
|
172
|
+
"b": 1
|
173
|
+
}
|
174
|
+
}
|
175
|
+
]
|
176
|
+
"""
|
177
|
+
|
178
|
+
Scenario: Retrieving Stashes using Limits
|
179
|
+
Given the following Stash exists in the database:
|
180
|
+
"""
|
181
|
+
{
|
182
|
+
"_id": "topic1",
|
183
|
+
"b": 1
|
184
|
+
}
|
185
|
+
"""
|
186
|
+
And the following Stash exists in the database:
|
187
|
+
"""
|
188
|
+
{
|
189
|
+
"_id": "topic2",
|
190
|
+
"b": 1
|
191
|
+
}
|
192
|
+
"""
|
193
|
+
When the client sends a GET request to "/v3/organization/stashes" with the following body:
|
194
|
+
"""
|
195
|
+
{
|
196
|
+
"b": 1,
|
197
|
+
"limit": 1,
|
198
|
+
"order": "desc"
|
199
|
+
}
|
200
|
+
"""
|
201
|
+
Then the response status should be 200
|
202
|
+
And the response body should be:
|
203
|
+
"""
|
204
|
+
[
|
205
|
+
{
|
206
|
+
"topic": "topic2",
|
207
|
+
"b": 1
|
208
|
+
}
|
209
|
+
]
|
210
|
+
"""
|
211
|
+
|
111
212
|
Scenario: Creating Stashes without a Query
|
112
213
|
Given there are no matching Stashes in the database
|
113
214
|
When the client sends a POST request to "/v3/organization/stashes" with no body
|
data/lib/vayacondios.rb
CHANGED
metadata
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: vayacondios-client
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
version: 0.3.
|
4
|
+
version: 0.3.2
|
5
5
|
prerelease:
|
6
6
|
platform: ruby
|
7
7
|
authors:
|
@@ -13,7 +13,7 @@ authors:
|
|
13
13
|
autorequire:
|
14
14
|
bindir: bin
|
15
15
|
cert_chain: []
|
16
|
-
date: 2014-
|
16
|
+
date: 2014-03-11 00:00:00.000000000 Z
|
17
17
|
dependencies:
|
18
18
|
- !ruby/object:Gem::Dependency
|
19
19
|
name: configliere
|
@@ -152,7 +152,7 @@ required_ruby_version: !ruby/object:Gem::Requirement
|
|
152
152
|
version: '0'
|
153
153
|
segments:
|
154
154
|
- 0
|
155
|
-
hash: -
|
155
|
+
hash: -2388885821583862613
|
156
156
|
required_rubygems_version: !ruby/object:Gem::Requirement
|
157
157
|
none: false
|
158
158
|
requirements:
|
@@ -161,7 +161,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
|
|
161
161
|
version: '0'
|
162
162
|
segments:
|
163
163
|
- 0
|
164
|
-
hash: -
|
164
|
+
hash: -2388885821583862613
|
165
165
|
requirements: []
|
166
166
|
rubyforge_project:
|
167
167
|
rubygems_version: 1.8.23
|