adelevie/parse-ruby-client

A simple Ruby client for the parse.com REST API

parse-ruby-client's Issues

weird behavior with files

1.9.3p194 :069 > colleague
#=>
{
                   "user" => _User:bKQ4rNeSqp,
                  "email" => "[email protected]",
               "facebook" => "",
    "methodOfLastContact" => "sms",
                   "name" => "Foo Bar",
                 "number" => "1 234 5678",
                  "photo" => #<Parse::File:0x007fa4090c49c8 @url="http://files.parse.com/f75-68d6-4694-ac03-aed9af458d7b/2c2f54cd-792d-453e-833b-63b14f1a7066-file">,
              "createdAt" => "2013-03-10T15:10:02.355Z",
              "updatedAt" => "2013-03-10T15:10:22.673Z",
               "objectId" => "5kGUdPgy9G"
}
1.9.3p194 :070 > colleague.save
Parse::ParseProtocolError: 111: File name must be a string.
  from /Users/mikesilvis/.rvm/gems/ruby-1.9.3-p194/gems/parse-ruby-client-0.1.14/lib/parse/client.rb:100:in `request'
    from /Users/mikesilvis/.rvm/gems/ruby-1.9.3-p194/gems/parse-ruby-client-0.1.14/lib/parse/object.rb:105:in `save'
    from (irb):70
    from /Users/mikesilvis/.rvm/rubies/ruby-1.9.3-p194/bin/irb:16:in `<main>'
1.9.3p194 :071 > Parse::Query.new("Colleague").eq("objectId", "5kGUdPgy9G").get.first.save
Parse::ParseProtocolError: 111: File name must be a string.
    from /Users/mikesilvis/.rvm/gems/ruby-1.9.3-p194/gems/parse-ruby-client-0.1.14/lib/parse/client.rb:100:in `request'
    from /Users/mikesilvis/.rvm/gems/ruby-1.9.3-p194/gems/parse-ruby-client-0.1.14/lib/parse/object.rb:105:in `save'
    from (irb):71
    from /Users/mikesilvis/.rvm/rubies/ruby-1.9.3-p194/bin/irb:16:in `<main>'
1.9.3p194 :072 >

Syntax for complex queries

See https://gist.github.com/4611516#file-query-rb

Error "new object used in context requiring pointer" when trying to use DateTime

I'm trying to get the count of objects created after a certain day, and keep getting the error "new object used in context requiring pointer". This is my code:

  item_count = Parse::Query.new("Item").tap do |q|
    q.limit = 0
    q.less_than("createdAt", Parse::Object.new(DateTime.now))
    q.count
  end.get
  @item_count = item_count["count"]

Have parse_resource depend on parse-ruby-client

Not really much to do here, but just an FYI to anyone developing with parse-ruby-client:

adelevie/parse_resource#71

Can you add support for windows 8 push notifications? parse already has

Is there any support for windows 8 push notifications, if not when is it getting added?

Saving nested object raises on pointer

I was using the latest released gem and noticed that nested objects weren't created.
Upgraded to the latest master but I still cannot save nested objects as pointers.

With a hash:

inspection_site = { attr: 'test' }

field_inspection = Parse::Object.new('FieldInspection')
field_inspection['inspectionSite'] = inspection_site
field_inspection.save

/Users/kain/.rvm/gems/ruby-2.0.0-p247@im/bundler/gems/parse-ruby-client-0eb452b0882d/lib/parse/client.rb:117:in `request': 111: invalid type for key inspectionSite, expected *FieldInspectionSite, but got object (Parse::ParseProtocolError)

With a Parse object:

inspection_site = Parse::Object.new('FieldInspectionSite')

field_inspection = Parse::Object.new('FieldInspection')
field_inspection['inspectionSite']  = inspection_site
field_inspection.save

/Users/kain/.rvm/gems/ruby-2.0.0-p247@im/bundler/gems/parse-ruby-client-0eb452b0882d/lib/parse/util.rb:56:in `pointerize_value': new object used in context requiring pointer FieldInspectionSite: [snip]

Related commit: 653145a

If I save the FieldInspection object first then the field_inspection.save works.
Am I doing something wrong or is it a bug?

User::authenticate doesn't work

For some reason, the password isn't getting sent to Parse when authenticating users. Here's Parse's doc on the method. This one's really baffling.

The relevant files are lib/parse/user.rb, lib/parse/protocol.rb (where some of the constants are defined), lib/parse/object.rb (since Parse::User inherits from Parse::Object), and probably lib/parse/client.rb.

$ rake test
WARNING: 'require 'rake/rdoctask'' is deprecated.  Please use 'require 'rdoc/task' (in RDoc 2.4.2+)' instead.
    at /Users/adelevie/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/rdoctask.rb
/Users/adelevie/.rvm/rubies/ruby-1.9.2-p290/bin/ruby -I"lib:lib:test" -I"/Users/adelevie/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib" "/Users/adelevie/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/rake_test_loader.rb" "test/**/test_*.rb" 
Loaded suite /Users/adelevie/.rvm/gems/ruby-1.9.2-p290/gems/rake-0.9.2.2/lib/rake/rake_test_loader
Started
............E.
Finished in 1.717421 seconds.

  1) Error:
test_login(TestUser):
Parse::ParseError: 201: missing user password
    /Users/adelevie/programming/parse-ruby-client/lib/parse/client.rb:47:in `request'
    /Users/adelevie/programming/parse-ruby-client/lib/parse/user.rb:14:in `authenticate'
    /Users/adelevie/programming/parse-ruby-client/test/test_user.rb:33:in `test_login'

14 tests, 29 assertions, 0 failures, 1 errors, 0 skips

Remove noop in push

https://github.com/adelevie/parse-ruby-client/blob/master/lib/parse/push.rb#L17

Limit attribute on Query is not working

Am I doing something wrong?

Here is the example:

valor_100primeiros = 0

query_hundred_values = Parse::Query.new(akatu_class)
query_hundred_values.limit = 200
hundred_values = query_hundred_values.get
hundred_values.each { |linha| valor_100primeiros += 1}

print valor_100primeiros

The output is:

100

Updating a fetched object fails.

If you fetch an object from the server using a query, update it, then save it, the save fails because the 'updatedAt' key is not being removed from the batch. The fix is to add the 'updateAt' key to the RESERVED_KEYS list in protocol.rb, patch incoming.

cant push with quey "where"

This is not working

push = Parse::PushMK.new({"alert" => "I'm sending this push to all my app users!"})
push.where = {"deviceToken" => "mytoken"}
push.save

with error message

Can't set channels for a query-targeted push

this is because @channel is set when "where" is defined. There should be in class Push

      if @where
        body.merge!({ :where => @where })
        body.delete :channel
      end

Abstracted batch methods

I just want to run through this before I submit a PR.

• get_object_count(class_name)
  abstracts a count query
• get_all_objects(class_name)
  hits a max of 11 000
• delete_all_objects(class_name or array of Parse::Objects)
  hits a max of 11 000 with class_name, but can run more than once to get around that

I've got them in util.rb right now, but that doesn't seem quite perfect. They're batch/query operations but wouldn't be instance methods of those objects. Thoughts?

Any other methods that come to mind?

Query conditions completely ignored

With parse-ruby-client 0.1.2 and ruby 1.8.7 on Mac OS X 10.7.5, I am seeing a major issue in which query conditions are ignored.

I adapted one of your unit tests to reduce the issue to its core.

require 'rubygems'
require 'json'
require 'parse-ruby-client'

Parse.init

foo = Parse::Object.new "Post"
foo["random"] = rand
foo.save
foo_query = Parse::Query.new("Post").eq("random", foo["random"])
print "1 == #{foo_query.get.size}\n"

bar = Parse::Object.new "Post"
bar["random"] = rand
bar.save
bar_query = Parse::Query.new("Post").eq("random", bar["random"])
print "1 == #{foo_query.get.size}\n"

query = foo_query.or(bar_query)
print "2 == #{foo_query.get.size}\n"

This is printing

1 == 1
1 == 2 <-- error
2 == 2 

The Post objects on Parse (as per the Data Browser):

objectId     random 
RqfRUhQLF4   0.959963811455423
6oF7tJXjvW   0.754638272517693

Resaving entire objects instead of only what has changed

I noticed that this client seems to be sending back to Parse the entire object instead of a delta.

For instance if we update a user object's 'username' we don't need to resave 'createdAt', 'updatedAt', and other fields/properties.

https://www.parse.com/docs/rest#objects-updating

Trying to create the special Parse "Installation" object for push notifications creates a new custom class called "Instllation"

When trying to create a new Installation object for push notifications, instead of getting a new object from the Parse "special type" Installation, a new custom class is being created.

Code:
new_user = Parse::Object.new "Installation"
new_user["deviceType"] = "ios"
new_user["deviceToken"] = ios_token
new_user["channels"] = Array.new
new_user["channels"] << ""
new_user.save

Parse::Query should do some validation on constraint arguments

so you can't do stuff like pass a DateTime to greater_than when you really needed a Parse::Date

Cannot update object with User as property

Let's say I have "Game" class and one object of that class has a property "firstPlayer" and another "secondPlayer".

This is what ap prints out for this game object's firstPlayer.

"firstPlayer" => {
          "coins" => 400,
    "displayName" => "Run4TheCup",
       "username" => "run4thecup",
      "createdAt" => "2012-12-31T01:27:53.792Z",
      "updatedAt" => "2013-01-19T04:39:17.992Z",
       "objectId" => "rLp66RJ6OH",
         "__type" => "Object",
      "className" => "_User"
},

Doing a save on this game object is failing:

/Users/bhammond/.rvm/gems/ruby-1.9.3-p374/gems/parse-ruby-client-0.1.12/lib/parse/client.rb:65:in request': 111: invalid type for key firstPlayer, expected *_User, but got object (Parse::ParseProtocolError) from /Users/bhammond/.rvm/gems/ruby-1.9.3-p374/gems/parse-ruby-client-0.1.12/lib/parse/object.rb:105:insave'

rcov problem

Hi,
I try to run test locally on my machine but it says that:
during bundle install for rcov => Ruby 1.9 is not supported. Please switch to simplecov
Checked the gem github page
https://github.com/relevance/rcov#why-what

Really strage thing for me is: Why Travis CI is working correctly?
In .travis.yml is 1.9.2 and 1.9.3 ruby. Anyone could explain it?

Need version bump to 0.0.6 after fix for #8

0.0.5, the latest gem available, still lacks the "updatedAt" fix. Can I request a version bump, please, so we can deploy code that this depends on into an environment in which we can't manually build the gems? Thanks in advance...

save silently ignores boolean fields set to false

this is the code to reproduce the bug:

# first, I drop MyClass in the parse.com data browser
# create and save object
o = Parse::Object.new("MyClass")
o["booleanField1"] = false
o["booleanField2"] = true
o = o.save
puts o["booleanField1"] # false
puts o["booleanField2"] # true
# get object and read boolean field
a = Parse::Query.new("MyClass")
    .eq("objectId", o["objectId"])
    .get.first
puts a["booleanField1"] # nil
puts a["booleanField2"] # true

The online parse data browser confirms this, the column "booleanField1" is completely missing. I put in lib/client.rb, function request(..), this debug print:

puts body

and I get this:

{"booleanField1":{"__op":"Delete"},"booleanField2":true}

the actual request sent to parse servers is wrong, and it seems a false is interpreted as some kind of delete field..

I'm on ruby 1.9.3p286 and parse-ruby-client 0.1.14

TODO means not implemented?

I found a lot of TODO in the docs. Event the object delete method is not implemented??

non-object hashes (such as ACL) are made into faulty Parse::Object instances in JSON parsing

this one is pretty simple, here's a test that illustrates the failure:

def test_hashes
  VCR.use_cassette('test_hashes', :record => :new_episodes) do
    foo = Parse::Object.new("Foobar", "foobar" => { "baz" => "123" })
    assert_equal Hash, foo["foobar"].class

    foo.save
    assert_equal Hash, foo["foobar"].class

    foo = Parse.get("Foobar", foo.id)
    assert_equal Hash, foo["foobar"].class
  end
end

The failure is <Hash> expected but was <Parse::Object> (in the third assertion). The resulting Parse::Object doesn't have a class_name nor an objectId. It should just stay a hash.

A JSON text must at least contain two octets!

I think this might be an issue in the JSON parser?

    [2013-07-31T21:32:05.718626 #9653]  WARN -- : Retrying Parse Error #<JSON::ParserError: A JSON text must at least contain two octets!> on request /1/users nil response #<Patron::Response @status_line='HTTP/1.1 502 BAD_GATEWAY'>

/Users/ddavtian/.rvm/rubies/ruby-2.0.0-p0/lib/ruby/2.0.0/json/common.rb:155:in `initialize': A JSON text must at least contain two octets! (JSON::ParserError)
from /Users/ddavtian/.rvm/rubies/ruby-2.0.0-p0/lib/ruby/2.0.0/json/common.rb:155:in `new'
from /Users/ddavtian/.rvm/rubies/ruby-2.0.0-p0/lib/ruby/2.0.0/json/common.rb:155:in `parse'
from /Users/ddavtian/.rvm/gems/ruby-2.0.0-p0/gems/parse-ruby-client-0.1.15/lib/parse/client.rb:102:in `request'
from /Users/ddavtian/.rvm/gems/ruby-2.0.0-p0/gems/parse-ruby-client-0.1.15/lib/parse/query.rb:127:in `get'
from new_facebook_user_notify.rb:56:in `compareFacebookFriendsToParse'
from new_facebook_user_notify.rb:99:in `<main>'

server errors show up as empty ParseProtocolError

parsed is sometimes nil on server errors in which case you get a blank exception

#<Parse::ParseProtocolError: : >

from

    if response.status >= 400
      raise ParseProtocolError.new(parsed)
    end

Parse::UserCannotBeAlteredWithoutSessionError

I have an admin interface and I am trying to edit users through the interface and I am seeing the following error being thrown: Parse::UserCannotBeAlteredWithoutSessionError

I am indeed using the MASTER-KEY on the account as such.

Parse.init :application_id => "APP_ID_GOES_HERE",
:master_key => "MASTER_KEY_GOES_HERE"

Any help is very appreciated.

Deleting a user fails

I've passed the master key in as an arg to Parse.init.

Here is the query and how I'm trying to delete the user objects.

users = Parse::Query.new("_User").get
users.each do |u|·
puts u.class
u.parse_delete·
end

I'm getting the Parse::UserCannotBeAlteredWithoutSessionError. Is there a different way I should be retrieving users that will make this work?

Better support for Batch Operations

See https://parse.com/docs/rest#objects-batch

Parse now lets you send up to 20 operations per request. I've added basic support for this:

batch = Parse::Batch.new
batch.add_request({
  "method" => "POST",
  "path" => "/1/classes/GameScore",
  "body" => {
    "score" => 1337,
    "playerName" => "Sean Plott"
  }
})
resp = batch.run!

While this is nice to get started, I don't like how you still need to manually construct the "path" value. First, the version number should be implied since it's already stored in Parse::Protocol. Second, shouldn't there be a better and more concise way to construct the rest of the path?

Perhaps something like this would be better:

batch = Parse::Batch.new
20.times do |i|
  obj = Parse::Object.new("Widget")
  obj["foo"] = i
  batch.add_object(obj)
end
batch.run!

If the object has an objectId, Parse::Batch would then know to send a PUT request to the endpoint "/1/classes/Widget" with the proper attributes in the payload. If, there is no objectId, then Parse::Batch would send a POST instead. I'm not quite sure how this would/should handle deletes, but I'd be open to suggestions.

@ericcj, do you have any thoughts on this?

Offering commit access

If (nearly) anyone reading this would like, I'm offering commit access to this project. I'm not planning on decreasing my time and effort spent here, but wanted to offer others the chance to move the project forward.

@ericcj, I know I've asked you before and you were not interested, but the offer is on the table if you ever change your ming.

As I said before, I still plan on actively maintaining and developing, but this could be nice opportunity for anyone looking to step up their open source experience.

order is not working...

Any news on how you are doing on this issue?

I was trying to use the parse_resource also but doesn't seem to implement the order

Retrieving All Objects is limiting by the firsts 100 rows

Here is the example:

valor_todos = 0

all_values = Parse.get "MyClass"
all_values.each { |linha| valor_todos += 1}

print valor_todos

The output is:

100

Support $include operator

which would require refactoring how pointers are handled. probably worth folding them into Parse::Object so it has a fetch_if_needed and transparently converts to a pointer on save like the official SDK's. have to look into how those SDK's support the Parse "Object" type that allows you to save an entire hash into a column though and replicate that behavior too

value_in should limit number of values

at some point it gets too long and Parse seems to just ignore it. 20 works for me

Invalid type for key location, expected geopoint

I'm trying to use the Gem's GeoType datatype like this:

def save
  if (!valid?)
    return false
  else
    parking = Parse::Object.new("Parking")

  data =
  {
    "longitude" => 40.0,
    "latitude" => -30.0
  }

  point = Parse::GeoPoint.new(data)

  parking["name"]             = name
  parking["address"]          = address
  parking["city"]             = city
  parking["location"]         = point
  parking["contributorName"]  = contributor_name
  parking["contributorEmail"] = contributor_email

  if (parking.save)
    return true
  end
end

end

and it returns me : " Invalid type for key location, expected geopoint"

I had to use:

parking["location"] = {"__type" => "GeoPoint", "latitude" => latitude.to_f, "longitude" => longitude.to_f}

in order to make this work.

Is this normal? What's the purpose of the GeoPoint class in the gem if we have submit an hash? At first I thought it was for fetching data only, but I still access the longitude/latitude using <%= parking["location"]["longitude"] %> ...

Thank you !

Parse::Date should support Times and Dates not just DateTimes

serialization should probably just give you DateTimes and coerce any of these instead of handing out Parse::Dates in the first place, but at the very least we shouldn't blow up on Times and Dates, or even ActiveSupport::TimeWithZone

replace user save with lookup on duplicate data errors

it's possible for user saves to be retried on timeouts but have actually succeeded in creating the user, in which case we raise

HTTP Status 400 Body {"code":202,"error":"username miUnNsGPHt already taken"}

but we should be looking up the user that was created on the previous retry in those cases so as not to have the same bug as https://parse.com/questions/username-already-taken-error-on-signup-retry

Multi threading issue.

Hey,

I have been running my code in a single thread without issue. But as soon as I run two threads problems arise.

Parse::ParseProtocolError
: unauthorized
/home/deploy/.rvm/gems/ruby-2.0.0-p195/gems/parse-ruby-client-0.1.15/lib/parse/client.rb:106:in `request'
/home/deploy/.rvm/gems/ruby-2.0.0-p195/gems/parse-ruby-client-0.1.15/lib/parse/object.rb:120:in `save'
/home/deploy/gametime-backend/lib/stubhub_page.rb:24:in `putsSh'
/home/deploy/gametime-backend/lib/stubhub_page/login.rb:17:in `block in process'
/home/deploy/gametime-backend/lib/stubhub_page/login.rb:16:in `each'
/home/deploy/gametime-backend/lib/stubhub_page/login.rb:16:in `process'
/home/deploy/gametime-backend/lib/stubhub.rb:48:in `block (2 levels) in submit'
/home/deploy/gametime-backend/lib/stubhub.rb:42:in `each'
/home/deploy/gametime-backend/lib/stubhub.rb:42:in `block in submit'
/home/deploy/gametime-backend/lib/stubhub.rb:40:in `each'
/home/deploy/gametime-backend/lib/stubhub.rb:40:in `submit'
/home/deploy/gametime-backend/app/purchase_flow.rb:73:in `block (2 levels) in <top (required)>'

Occasionally I get the following error, which seems related:

WARN -- : Retrying Parse Error #<Patron::TimeoutError: easy handled already used in multi handle> on request /1/classes/PurchaseFlow nil "{...}]}}" response nil
...
[2013-07-17 18:40:29] ERROR Patron::Error: easy handled already used in multi handle
/home/bwinter/.rvm/gems/ruby-2.0.0-head/gems/patron-0.4.18/lib/patron/session.rb:223:in `handle_request'

I think it's unrelated but occasionally it segfaults as well (I think this is a selenium issue). The full error is massive so I will supply that upon request:

/home/bwinter/.rvm/gems/ruby-1.9.3-p429/gems/childprocess-0.3.9/lib/childprocess/abstract_process.rb:138: [BUG] Segmentation fault

I am not quite sure what's causing the issue here. I create my parse object then create a new thread that starts using it. If I remove every 'parse.save' in my code I can run multiple threads w/o issue. So I can only assume Parse is somehow causing these issues. Maybe the shared application_id/api_keys...

Parse.init(:application_id => "...", :api_key => "...")
parse = Parse::Object.new("PurchaseFlow", initial_data).save
Thread.new{ Processor.new.submit(parse) }

As you can see from my stack traces I have tried quite a few versions of ruby (1.9.3, 2.0.0-193p,247p,270p), none of them seemed to help.

Gemfile:

    braintree (2.23.0)
      builder (>= 2.0.0)
    builder (3.2.2)
    childprocess (0.3.9)
      ffi (~> 1.0, >= 1.0.11)
    excon (0.16.10)
    ffi (1.9.0)
    iron_core (0.6.2)
      rest (>= 2.2.0)
    iron_mq (4.0.3)
      iron_core (>= 0.5.1)
    json (1.7.7)
    jwt (0.1.8)
      multi_json (>= 1.5)
    kgio (2.8.0)
    mandrill-api (1.0.37)
      excon (~> 0.16.0)
      json (~> 1.7.7)
    mime-types (1.23)
    multi_json (1.7.7)
    net-http-persistent (2.8)
    parse-ruby-client (0.1.15)
      iron_mq
      patron
    patron (0.4.18)
    rack (1.5.2)
    rack-protection (1.5.0)
      rack
    raindrops (0.11.0)
    rest (2.6.3)
      net-http-persistent
      rest-client (>= 0.3.0)
    rest-client (1.6.7)
      mime-types (>= 1.16)
    rmagick (2.13.2)
    rubyzip (0.9.9)
    selenium-webdriver (2.33.0)
      childprocess (>= 0.2.5)
      multi_json (~> 1.0)
      rubyzip
      websocket (~> 1.0.4)
    sinatra (1.4.3)
      rack (~> 1.4)
      rack-protection (~> 1.4)
      tilt (~> 1.3, >= 1.3.4)
    tilt (1.4.1)
    twilio-ruby (3.9.0)
      builder (>= 2.1.2)
      jwt (>= 0.1.2)
      multi_json (>= 1.3.0)
    unicorn (4.6.3)
      kgio (~> 2.6)
      rack
      raindrops (~> 0.7)
    websocket (1.0.7)
    zbar (0.2.2)
      ffi (>= 1.0.0)

If there is any missing information that might help, let me know.

Thanks,
Brendan

should retry on server-side errors

#<JSON::ParserError: 757: unexpected token at '<html><body><h1>502 Bad Gateway</h1>

#<JSON::ParserError: 757: unexpected token at '<html><body><h1>503 Service Unavailable</h1>
No server is available to handle this request.
</body></html>

#<JSON::ParserError: A JSON text must at least contain two octets!>
gems/ruby-1.9.3-p194/gems/json-1.7.3/lib/json/common.rb:155:in `initialize' -- ge
ms/ruby-1.9.3-p194/gems/json-1.7.3/lib/json/common.rb:155:in `new' -- gems/ruby-1.9.3-p194/gems/json-1
.7.3/lib/json/common.rb:155:in `parse' -- gems/ruby-1.9.3-p194/gems/parse-ruby-client-0.1.2.ericcj.1/l
ib/parse/client.rb:58:in `request' -- gems/ruby-1.9.3-p194/gems/parse-ruby-client-0.1.2.ericcj.1/lib/p
arse/query.rb:82:in `get'

Multi Threading | Sidekiq

Hi!

I am in the same situation as #98

I've been running some code single threaded for a few months without any problems. That code calls Parse::Push. Recently, we move some of that code to use http://sidekiq.org/ and we are seeing some error for the first time. They are:

Parse::ParseProtocolError: : unauthorized
Patron::HostResolutionError
Patron::URLFormatError

Not sure if all the exceptions are related to thread safety. I'll investigate further.

I am not a thread safety expert, but I would love to collaborate on making this gem thread safe. At least, the push notifications part. 😄

A quick peak into the code reveals:

https://github.com/adelevie/parse-ruby-client/blob/master/lib/parse/client.rb#L183

Is a singleton needed for the client?

createdAt and updatedAt are left in Parse::Object hash as Strings

which means they're passed around as strings which will never match conditions if you do something like:

2.0.0-p0 :011 > Parse::Query.new('_User').greater_than('createdAt', Parse::Query.new('_User').get.first['createdAt']).get
2013-05-23 17:16:06 [INFO] Parse query for /1/users {"where"=>"{}"}
2013-05-23 17:16:07 [INFO] Parse query for /1/users {"where"=>"{"createdAt":{"$gt":"2013-05-02T15:25:43.714Z"}}"}

push: expiration_interval not expiration_time_interval

  body.merge!({ :expiration_time_interval => @expiration_time_interval }) if @expiration_time_interval

According to the docs, it appears to be expiration_interval

https://parse.com/docs/push_guide#options-expiry/REST

provide async api everywhere we provide a synchronous one: Query#get, Object#save, etc.

we could split out a version of this gem as an eventmachine protocol, and might want to do that anyways, but it would be nice to offer an async api without requiring they be using eventmachine. faraday appears to be the best way to do that, so we would need to get #88 merged then implement asynchronous versions of the api like:

query.get_async do |results|

access results Array here like you would from the synchronously returned one

end

these would use a Faraday middleware to call the block you pass as in http://blog.carbonfive.com/2013/03/15/parallel-http-requests-with-faraday-and-typhoeus/ with us passing the block through env via:

@session.get(...) do |request|
request.options["pf_block"] = block
end

and could therefore be nested inside the parallel faraday api as follows:

foos = nil
bars = nil

Parse.client.session.in_parallel do 
  Parse::Query.new("Foo").get_async do |f|
    foos = f
  end

  Parse::Query.new("Bar").get_async do |b|
    bars = b
  end
end

puts foos + bars

it appears that nesting async calls within the callbacks of others would work

How to do file upload using parse-ruby-client?

creating Installations

I see this is TODO

is there a way using Parse::Object to do so ? or another not so straightforward way ?

thanks.
Jodi

Relational data seems broken

When i try to run the following example from the ReadMe:

post = Parse::Object.new "Post"
post.save

comment = Parse::Object.new "Comment"
comment.save

post.array_add_relation("comments", comment.pointer)
post.save

It just gives me the following error:

undefined method `array_add_relation' for #<Parse::Object:0x007f80d441d820>

Are the relationships broken or am I doing something wrong?

Suggestions for 1.0 milestone

Discuss. Feel free to write the problem inline as a comment or just to link to an issue or PR.

Ideally, full parity with all of Parse's REST features would be nice. Wondering how others feel?

In some ways, I'm really happy with the stability of the codebase. Everything is pretty modular and magic-free. That said, some issues like delta-saving are still bugging me.

Boolean

I don't think using regular ruby booleans is working. I'm trying to set something like Parse::Object['item'] = false and it doesn't give me an error, but It never saves in the API and doesn't fail with an error. Everything else saves, but it ignores the item with the boolean value

Support X-Parse-Master-Key

in place of rest api key which limits your access priveleges

DSL for Parse::Query#in_query

Here's the current usage:

Assume I have the classes Post, Tags, and PostTags (which joins the first two).
def in_query(field, query)
query_hash = {Parse::Protocol::KEY_CLASS_NAME => query.class_name, "where" => query.where}
add_constraint(field, "$inQuery" => query_hash)
self
end

post_tags = Parse::Query.new("PostTag").tap do |q|
  q.in_query("tag", Parse::Query.new("Tag").tap do |tq|
    tq.eq("category", "Person")
  end)
end.get

And here's what I propose:

post_tags = Parse::Query.new("PostTag").tap do |q|
  q.in_query("tag") do |tag_query|
    tag_query.eq("category", "Person")
  end
end.get

Is this something anyone (@ericcj, @jamonholmgren) would want?

decrement should be increment with amount -1

sending Decrement is just a noop that doesn't raise an error

separate Query#count method from Query#get just like the official parse sdk's

instead of returning a hash with count and potentially results in it. this would fix the documentation too, which makes it look like it just returns an integer. we could go back to strong validation in Query#count to require the response to be a json hash with "count" and similar for Query#get and "results" then instead of allowing whatever through. there also seems to be unnecessary stubbing in test_count.