This patch is about teaching services the concept of resources and CRUD operations. It's a must for any resource-based server implementations (read REST). The draft patch also makes resources available to method-oriented servers and methods available for resource-based servers, maintaining maximum compatibility with rpc-style service implementations.

Comments

Hugo Wetterberg’s picture

Status: Active » Needs review
StatusFileSize
new28.03 KB
Hugo Wetterberg’s picture

Added hook_service_resources_post_processing_alter().

The processing of '#retrieve'->'#relationships', '#update'->'#actions' and '#update'->'#targeted actions' inheritance logic is now handled in services_process_resource() instead of being spread out and inconsistently applied. Also added the missing processing for targeted actions.

Hugo Wetterberg’s picture

Rebased on the current 6.x-1.x branch and made a fix to the resource processing with regard to actions. See: http://github.com/hugowetterberg/services/commit/5fa316241539e6b126dc4c8...

marcingy’s picture

I want to get decoupling in before we tackle this patch - otherwise if we have 2 major changes hitting services core it is going to be interesting ;)

freelock’s picture

Subscribing... Is this getting in soon?

freelock’s picture

I just tried applying this patch to 6.x-2.x-dev. Trying to get rest_server-6.x-2.x-dev to work. Got one failed patch hunk, which was already applied--the rest applied pretty cleanly. But it looks like the RESTServer class in rest_server doesn't match the structure of resources passed by the patch.

Does anyone have the latest dev version of rest_server working?

I'd be happy to help finish off these interactions, if somebody can point me to which function should be patched--just breaking into this code, and not sure what's old and what's new.

Hugo Wetterberg’s picture

Hi freelock.
Here is a updated patch that should apply cleanly to the 6.x-2.x-dev branch. Any help, patches, et.c. would be very appreciated, both when it comes to CRUD in services and the REST server.

I'll take a look at the REST server to make sure that I've added the latest changes to CVS.

Cheers,
Hugo

freelock’s picture

Hi, Hugo,

I actually found your git repo and pulled from there before seeing your patch. I've got it all working at a basic level here, and am starting to put it to use.

I notice you use your own Query Builder module to handle parameters and fields in the web service. This is working fine--however, what I'm setting up to talk to the service passes '*' as a wild card for pretty much all searches. So I've added a very quick patch to that to support these searches (and it's gotten the first part of what I'm trying to do done!)

diff --git a/sites/all/modules/query_builder/QueryBuilder.inc b/sites/all/modules/query_builder/QueryBuilder.inc
index af40013..9d85c21 100644
--- a/sites/all/modules/query_builder/QueryBuilder.inc
+++ b/sites/all/modules/query_builder/QueryBuilder.inc
@@ -281,7 +281,11 @@ class QueryBuilder {
             }
           }
           // ...if not we treat it as a match condition
-          else {
+          elseif (strpos($value,'*') > -1) {
+            $col = $this->field_column($field);
+            $q->conditions[] = $col . ' LIKE ' . $placeholder;
+            $q->params[] = str_replace('*','%',$value);
+          } else {
             $col = $this->field_column($field);
             $q->conditions[] = $col . '=' . $placeholder;
             $q->params[] = $value;
-- 

1.6.0.4

... of course, this patch isn't good for Postgres, since LIKE is case-sensitive... I'm just learning the Drupal API -- is there a convention for making this more portable across databases?

Hugo Wetterberg’s picture

Hmm, I don't know about the cross-dbms issue. But it's hard to emulate case insensitivity if there isn't already a calculated field that has been transformed to lower or upper case that the LIKE with the similarly transformed pattern can be run against. There is a variable/function somewhere that can be used to check which backend the install uses. But I pretty much think that the case-sensitivity of the LIKE-operator is something you'll have to live with when using pgsql.

I've fixed a bug in the rest server that I pushed just now http://github.com/hugowetterberg/rest_server/commit/48872b2683074a58f8f8.... So feel free to fetch the updated code. And you're welcome to fork the rest server over at github, forking is a good thing in the git world :) And it allows me to follow your work and easily integrate it into the rest server.

Cheers,
Hugo

marcingy’s picture

Status: Needs review » Fixed

Committed to head

robloach’s picture

Thanks Hugo and Marc, this is awesome.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.