Forum Discussion
board uids are "internal" ids and differ from stage to prod, so we do not expose them via the API. the board id we do display is the string-based id that was chosen for the board when it was created.
-Doug
- rayinala8 years agoMentor
Hi DougS,
The response of Bulk Data API contains the board.uid not the actual boardId. So if we want to pull the full details of Board, we see fetching with boardId is the only way in v2API. Could you please guide us how we can solve this issue?
Thanks,
Ramesh
- luk8 years agoBoss
Good point rayinala, if other Lithium "modules" like Bulk Data API etc. return data only in a specific way DougS it should be possible to also use this data with v2, otherwise we'll never get away from v1 =)...something like this should be possible:
// Bulk API will return something like this for ancestors: "/1/2/176/177/244/" // we can do "/1/2/176/177/244/"?split("/")?join(",") as preparation for the v2 query SELECT * FROM nodes WHERE uid IN(1,2,176,177,244)
I get the point that the ID's are different on stage and prod, but why does that matter? In the end we should not hardcode uids into code, especially when we know they are not the same over all instances, but that's not a reason to not expose them IMHO.
- DougS8 years agoKhoros Oracle
This seems like it was an oversight in the design of the LSI Bulk API. The numerical node ID was supposed to be an internal ID that was not to be exposed externally. Unfortunately it looks like it has been exposed via this API. I will certainly raise this with the Product team to see if we can expose a way to look up nodes by their numerical IDs (and/or if we want to change the LSI Bulk API to expose the string-based node ids instead of / in addition to the numerical node ids).
-Doug
Related Content
- 9 months ago
- 10 months ago
- 3 years ago
- 2 years ago