What problem are you trying to solve?
A cache file becomes a full Jackson tree, then a full org.json tree, then 31,053 objects of 48 fields each - to answer six accessors in the selection loop. Movie.java:26-38 and every sibling; MovieResource has 48 fields.
Projecting at parse time to just what the updater reads measured 5.1-7.8 MB retained against 97-104 MB, and removes most of the 447 ms spent building DTOs per cycle. Per item, ~8,700 bytes are held to make a decision that needs 172-253.
What would you like Fetcharr to do?
A lightweight selection view for the loop, with the full resource fetched only for the handful actually chosen - and the fetch event carrying ids plus a supplier rather than a materialised list. That keeps the plugin capability intact while making it pay-per-use.
Depends on the raw-payload question: node() is on the public FetchableAPIObject interface and AbstractAPIObject already gates its equivalent behind PROVIDE_RAW_API_OBJ. Two levels of the same object model currently make opposite calls, and picking one is a prerequisite for this.
What alternatives have you considered, if any?
This one is not free, and it's the reason it's a design issue rather than a fix.
WhisparrUpdater.java:51 posts new WhisparrFetchMovieEvent(all, ...) - the entire Movie, all 31,053 full DTOs, with a raw tree still reachable through event.movie().node() - onto the plugin event bus. No in-repo listener consumes it, but the API is built so a plugin can.
So "nothing needs the full DTO" is true of the updater's own loop and false of the system as designed. Projecting without addressing that would silently narrow what plugins receive.
What problem are you trying to solve?
A cache file becomes a full Jackson tree, then a full org.json tree, then 31,053 objects of 48 fields each - to answer six accessors in the selection loop.
Movie.java:26-38and every sibling;MovieResourcehas 48 fields.Projecting at parse time to just what the updater reads measured 5.1-7.8 MB retained against 97-104 MB, and removes most of the 447 ms spent building DTOs per cycle. Per item, ~8,700 bytes are held to make a decision that needs 172-253.
What would you like Fetcharr to do?
A lightweight selection view for the loop, with the full resource fetched only for the handful actually chosen - and the fetch event carrying ids plus a supplier rather than a materialised list. That keeps the plugin capability intact while making it pay-per-use.
Depends on the raw-payload question:
node()is on the publicFetchableAPIObjectinterface andAbstractAPIObjectalready gates its equivalent behindPROVIDE_RAW_API_OBJ. Two levels of the same object model currently make opposite calls, and picking one is a prerequisite for this.What alternatives have you considered, if any?
This one is not free, and it's the reason it's a design issue rather than a fix.
WhisparrUpdater.java:51postsnew WhisparrFetchMovieEvent(all, ...)- the entireMovie, all 31,053 full DTOs, with a raw tree still reachable throughevent.movie().node()- onto the plugin event bus. No in-repo listener consumes it, but the API is built so a plugin can.So "nothing needs the full DTO" is true of the updater's own loop and false of the system as designed. Projecting without addressing that would silently narrow what plugins receive.