1

I am trying to explore the opportunity to build a connector for CouchDB for Loopback.io. I know CouchDB has a REST interface but - for some reason - when putting the baseURL of my Couch local server into a Rest connector in Loopback, I get an error back on some headers missing in the request from Couch. Since some useful functions could be added to exploit views and so on, I am exploring the loopback-connector-couchdb creation.

So easy question is: what are the methods that a connector needs to implement to map exactly to the standard API endpoints offered by Loopback.io for a model? Basic example:

  1. POST /models (with payload body) --> all good on the "create" function of the connector
  2. DELETE /models/{id} --> I get an error saying that the destroyAll function is NOT implemented (correct) but the destroy function IS implemented instead...
  3. what is the difference between HEAD /models/{id} and GET /models/{id}/exists in terms of the functions called?
  4. I try to verify the existence of the model created (successfully) in CouchDB via ID and use GET /models/{id}/exists and instead of having the function "exists" called in the Connector, another function called "Count" is called instead.
  5. It is as if some but not all functions are mapped to the connector (note, I am not using the DataAccessObject property of the connector, as that seems to be more for additional methods, so to speak... and one of the methods does work!)

...I am confused!

Thanks for any guidance. I am trying to follow this, but i can't easily map standard API endpoints to the minimum functions of the connector (see point 2 above, for instance) Building a connector - Loopback.io documentation

drmonkeyninja
  • 8,490
  • 4
  • 31
  • 59
Matteo
  • 11
  • 3

1 Answers1

0

I would suggest playing with the API explorer to figure out your endpoints.

  1. Create a sample LoopBack project via slc loopback
  2. Create some models via slc loopback:model
  3. Start the app via slc run
  4. Browse to localhost:3000/explorer

In there you can see all the endpoints that are automatically generated by LoopBack. Like if you click the GET endpoint for a model, it will show the query as GET /api/<modelname>.

superkhau
  • 2,781
  • 18
  • 9
  • Hi - thanks perhaps i have not been clear. I have got that far, in fact i am trying to understand one additional thing... if I tie the model to a connector, the curious thing that happens is as follows: the create method from the API maps exactly to the create prototype function of the connector, whereas the "exists" endpoint of the API does NOT map exactly to the exists function of the newly created connector. – Matteo Nov 24 '14 at 17:58
  • and happy to share the test NPM of the connector of course. – Matteo Nov 24 '14 at 18:28
  • Have you tried looking at the source code? You should be able to find an example from an existing connector. Maybe somewhere here: https://github.com/strongloop/loopback-connector-mongodb/blob/master/lib/mongodb.js#L253-L272 – superkhau Nov 24 '14 at 18:29
  • Looking forward to seeing your connector. Let me know when you finish it or if you need more info, I will try my best to get you an answer. Also, if you want, we can add your connector to our community contributions. See: https://github.com/strongloop-community?query= – superkhau Nov 24 '14 at 18:33
  • OK, i think i got where I think the issue seems to be. Let's loolk at the MongoDB connector for instance. It has a prototype function called "exists". However, if I create a model (a derived class of the "PersistedModel" class), it basically has the prototype methods in file "loopback-datasource-juggler/lib/dao.js". There, the function "exists" in fact calls the function "count" in the real connector... hence the function exists in the connector prototype is never called (unless it is called in a way that I can't see and happy to be guided). – Matteo Nov 24 '14 at 19:14
  • So this would explain why my "exists" prototype function in my infant CouchDB connector is not called but misteriously the "count function is called" – Matteo Nov 24 '14 at 19:15
  • OK-I am not going to submit a PR as it may affect other connectors and currently not involved. I have decided to adapt my strategy for the couchDB connector, but one question i have left is ... after creation of a single doc, I know we can pass back the ID and the REV (CouchDB requires REVs). After an update, however, it seems that the Model cannot take the REV update anymore (and so a subsequent update would fail onto couchDB). Is this correct? Is there a way around to pass back data to all models after saving? – Matteo Nov 26 '14 at 10:59