Learned today [in the VUG meeting] that Servoy caches SQL views at the time a session is instantiated. View data does not change even if you edit, from within Servoy, the table data that drives the view.
This means that Servoy’s picture of your view can become out of sync with the actual view unless you refresh the view’s entire foundset each time data that drives the view is modified.
Thought I would share…Maybe I have this wrong?
Jeff,
Yup, that’s what I heard. I am also thinking (if I get this right from Johan’s comments via Scott) that:
Views are treated as a “snapshot” by virtue of the foundset instance. I.e. - conceptually similar to a materialized view;
Views are treated, fundamentally, as non-editable sets;
Form data based on a view is non-editable.
Others: Please advise if the above is correct (anyway - this is the behaviour I notice against Postgres in Servoy rev 3.5).
Michael
Views are editable in servoy if the view is editable in the database.
Due to the fact that JDBC though which servoy connects to the database does not allow you to retrieve the underlying SQL statement of the view and because vieuws can display data from multiple tables in aggregated and grouped format, it is not possible for Servoy to know with column in which record in the view maps to what record in which table in the database.
Therefor, it’s not possible for servoy to take care of databroadcasting/keeping the datacache in sync.
Paul
Thanks, Paul - Postgres supplies a non-updatable view and so the observed behaviour.
I certainly understand the obvious challenges one would have attempting to write classes that would interact with the underlying and background tables of a view ~ all originally designed to be non-updatable by the backend db and so the JDBC design assumptions.
Theoretically possible I suppose and would probably make a nice one-year project for a dev team Definitely falls into the non-trivial category in terms of effort!
Quite happy with what Servoy is doing already!
Best,
Michael
Paul,
A ps on the last reply: I am thinking that some of the underlying View and related metaschema may be exposed further via Eclipse: http://eclipseplugincentral.com/Web_Lin … cid-3.html. I know the db modeling world pulls back the view’s underlying sql.
Someday, it would be very cool to wrap non-updatable views with Servoy data providers (opens up a very interesting market segment and broadens applications for a db).
For the future … (and a discussion over beer (by proxy - I can’t make Servoy World this year)).
Michael
Hi Paul,
Fundamentally, I think it’s great that Servoy has support for views, and I understand the limitation may be with JDBC (if I understood your post), but I also think that Servoy developers are most certainly misinformed (as I was) about exactly how views are handled by Servoy.
In particular, the concept that a view’s dataset is cached at instantiation and not “refreshed” when related data is edited within Servoy is something that should be documented (and if it is, I apologize as I have missed it). I for one have been using views within Servoy, making the assumption that those views would be managed by Servoy [in a manner consistent with how table data is managed], which of course is not the case. I think other developers have probably been working under the same premise as myself.
Thanks for all your hard work Servoy
Can somebody send a recipe of what to do in the case of displaying VIEWS in a form? Which would be the best way to do a “refresh” of the data stored in the backend database?
jcarlos:
Can somebody send a recipe of what to do in the case of displaying VIEWS in a form? Which would be the best way to do a “refresh” of the data stored in the backend database? :?
Like with any foundset you can (forcefully) invalidate the clients cache by using databaseManager.refreshRecordFromDatabase(foundset, -1) .
The -1 tells it to invalidate the whole cache.
Hope this helps.