Agreed. Really enjoying this one more and more.
These are all fantastic releases.
Iāve been trying to build an integration to Stock&Buy API Reference with the AI integration agent and canāt for the life of me get it to work with endpoints which have multiple pages. Iām somewhat technically competent (often write basic python) and was able to set up an app hosted on our own server to do data syncing. I was hoping the agent could make setting up new datastreams easier.
Does anyone have any experience with the new integration agent that they could share for newbies? any suggestions for how to do this more easily
I just wanted to say that āShow Fields from relation without Lookupā is one of the best features Fibery has added since multiple entity views!
The functionality doesnāt seem to allow the relationās relation fields to get displayed as ālevelsā in embedded views though, unless Iām missing something. Can we expect that to come in the future?
Agree with you thatās a good feature. On my use case I a would say that one thing is missing : having the possibility to set the relation field read only.
Sometimes I want to use a field from a relation for an informative purpose. In this case, I need to create an additional field (formula).
2 Likes
In that case, you might want to use a lookup. But I could imagine that if they just added the feature to choose between allowing a change, then the lookup field could disappearā¦ Less clutter in the workspace!
Yes, the idea is to reduce the qty of stuff. Iām not sure about all the use cases that a Lookup can cover but at least, if Read Only is added there, then the Lookup is probably no more necessary, for this use case.
āhaving the possibility to set the relation field read onlyā ā would be very nice!
As a clarification, lookup fields and related fields have different behaviours which all basically stem from the fundamental difference in how they work technically:
- Lookup fields are true backend fields, which belong to the database where they are defined. They behave like formula fields: calculated using a backend service (with a slight latency). A user can query the value of a lookup field via API as well as choosing to show them anywhere the entity can be shown.
- Related fields are merely frontend āfieldsā (that allow visualising field values from a related entity) rather than being true backend fields. When a user chooses to display a related field, the value(s) are being retrieved (from the linked entity) at display time. An API query of an entity does not allow a user to get these values.
Hopefully, this explains the differences in behaviour, e.g. why lookups are read-only, and hard to make behave otherwise, even though the two types appear rather similar on the UI.
1 Like
I tried making a custom integration using WFS (web feature service - we geo people have our own web service standards, they come from the OGC which is just 6 days younger than the W3C - yes Fibery, you wanted nerds, you get nerds! 
)ā¦ using this prompt:
can you make a custom integration with tables for me like the āWorldā integration, but then with country, provinces, municipalities in the netherlands?
Here is the WFS from PDOK: Gemeenten
this contains the necessary data.
However, it said it made an integration (and I saw it in the Editor) but I didnāt see one under integrations. I wonder what went wrong.
I believe itās working. Edit: look at the screenshot below. I have 3 levels of administrative divisions - Country, Province, Municipality. It comes from the official data service so when they merge municipalities then I can just sync again. Amazing.
