Closed (fixed)
Project:
Services
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
19 May 2009 at 12:59 UTC
Updated:
21 Sep 2009 at 19:20 UTC
Jump to comment: Most recent file
Comments
Comment #1
Hugo Wetterberg commentedComment #2
Hugo Wetterberg commentedAdded 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.
Comment #3
Hugo Wetterberg commentedRebased 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...
Comment #4
marcingy commentedI 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 ;)
Comment #5
freelockSubscribing... Is this getting in soon?
Comment #6
freelockI 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.
Comment #7
Hugo Wetterberg commentedHi 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
Comment #8
freelockHi, 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!)
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?
Comment #9
Hugo Wetterberg commentedHmm, 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
Comment #10
marcingy commentedCommitted to head
Comment #11
robloachThanks Hugo and Marc, this is awesome.