Is there any alternative in postgres to compile views as oracle? I searched ,but couldn't find any relevant alternatives for it . Can anyone suggest on this?
ALTER VIEW employee COMPILE; in oracle
In PostgreSQL views don't have to be compiled.
This is an Oracle specific nuisance. Oracle does not make sure that the dependencies of a view remain intact, so it can happen that a view becomes invalid because one of its requisites changed or vanished.
Oracle calls such a view invalid and calls the process of making sure all requisites are there compile.
In PostgreSQL, the database management system will prevent you from changing the requisites of a view in a way that might break the view, so a view can never become invalid. Hence there is no need to check its validity.
This is convenient, but it comes at the price that you have to drop and recreate the view if you want to modify an underlying table.
Related
Scenario
I have a wizard that all work on the same data object which is passed from step to step.
Steps:
Start
Some input values
Finish (draft becomes a actual db entry)
Current solution
Currently I use the old but working NavigationLink(isActive: ...). Now, I try to port my app to the new SwiftUI alongside iOS 16. That means the "old" NavigationLink is outdated. I tried NavigationStack with or without a $path, etc. pp
What's my actual problem?
All examples or great answers on SO I found (also from Apple) are "too simple" - I guess. I do not have a list, my navigation is "next"-Button-based. My "Destination view" is not just a TextField and I do not have a strict navigation flow (in future, there will be optional steps in between) as in the WWDC22 sample.
A step (aka View) will be also used in another wizard, too. Is this a good idea?
What I think, I need
My "wizard container view" I call it "flow" which embeds all other steps has to have a NavigationStack($path) {} component.
I have to make the path isn e.g. an EnvironmentObject that I can easily access and modify it during my wizard run from each child view.
I need a mapping using .navigationDestination(for: WizardNavigation.self) { switch ... } to show the requested next step.
But, what do I miss?
It feels over complicated and, again, to strict in navigation. The parent has to know all possible navigation destinations?
Please tell me, that I miss a big point that simplifies my whole approach.
This drove me crazy for a weekend, and although I found what seems to be a workable solution, my question is whether there is something fundamental about using Dojo/Dijit that I'm missing.
Here's the problem: Whenever I create page in which a dgrid uses a JsonRest store and is in a hidden tab of a TabContainer (one that is not the initially selected one), I get DOMExceptions and a somewhat screwed up dgrid. In particular, the dgrid has a large empty space under the last row of data, and scrolling to the bottom or top of the dgrid's data throws additional DOMExceptions.
If I click on one of the column headers to sort the dgrid, it resets its layout and works fine. If the dgrid initializes on a visible part of the page instead of an unselected tab, it's fine. If I use a Memory store instead of a JsonRest, everything's fine (even if the dgrid is initialized in a hidden tab). If the dgrid is initialized in a hidden tab but without a store, it's fine (but empty).
Based on the evidence, I guessed the problem had something to do with the fact that a JsonRest query takes time, and for some reason that's breaking dgrid when it's initializing. My solution was to create the dgrid without a store, and then set the store when its the tab containing the dgrid was shown. This seems kludgy, though. I should be able to create a dgrid with a store and not have to fiddle with it externally.
So, is my somewhat hack-ish solution the proper (or at least a reasonable) way to handle initializing a hidden dgrid with server-supplied data, or is there something about the setup of TabContainer+dgrid+JsonRest that I'm missing?
I don't have an answer to your question, but there is a contract between Dijit widgets and containers regarding the lifecycle and startup of a widget... in particular, when the elements are added to the DOM and, at the end, when the startup() method is called to layout and resize the elements. dgrid probably does not participate. Perhaps you can connect something to the TabContainer's startup method which will trigger a layout of the dgrid component?
Is there a way to achieve this? At first I thought that desctructionPolicy = 'never' would allow me to do this, but after spending a lot of time struggling with it, it seems I was wrong and the feature doesn't work as I thought.
I could keep all the relevant data I need of that view and restore all components to the expected state, but I find that to be a bit cumbersome, and I'm a bit surprised there is no way to do this. When I navigate through several views, and then go back up to the view I'd like to persist, it is there with its last state.
Can't I restore the view in the same way?
I guess this is not possible. At the end I had to store and restore the whole view.
It would be nice if Adobe would allow for this, luckily this may be one of those things where Flex being donated to the Apache foundation would come handy.
I'm a little confused about MVVM.
I understand the concept and can see the advantages. My problem is: does the ViewModel pass data directly from the model.
For example, let's say I have a "User" model with a findByName() method. The ViewModel would call this in order to pass
the relevant user details to the view.
The model would likely retrun a set of "User" objects each which has properties such as name, email address etc and may also have methods.
My question is, should the ViewModel return the set of User objects to the view, or return a restructured version of this which
contains only what the view needs?
As I understand it, the "User" object in this case is part of the model layer and in MVVM the View should be dependant only on the ViewModel.
My issue with this is the ammount of seemingly redundant binding logic required in the ViewModel that would be created to restructure the output.
Passing the set of User objects directly to the View (via the ViewModel) would be far simpler.
There's a little bit of redundancy, sure. However, if you implement MVVM by presenting the objects, you get to
format the model information for the view without polluting the model with presentation logic
notify the view when anything changes
use WPF's validation (if you're using WPF)
run acceptance tests from the VM level rather than the GUI if you want to
abstract your presentation away from any changes to the model.
That last one's important. Mostly presentation bindings nowadays are dynamic and fail silently - web pages, WPF, you name it. That means that if someone decides to rename something on the model, it will suddenly break in your GUI and you won't know.
By putting a VM between your Model and View you buffer yourself from changes like this.
If you want to go ahead and get something working with the Users as they are, I say go for it - it'll help you get fast feedback on your GUI. However, the first time those User objects don't do exactly what the View needs, or you need to notify the View of a change, or you find yourself polluting the model, or something in the binding breaks, maybe that's a good time to move to MVVM.
Doesn't that just move the break to the ViewModels which are using the model? You'd still need to go through and update all of those.
If I renamed something (e.g. changed "surname" to "lastname") I'd expect things to break. I don't see how adding the binding in the VM layer fixes that.
I have a few views in my database that im using in my ASP MVC-application. Now I am experiencing a very strange problem. There are 8 views in the database but even if I check them all in the Create Enity Data Model-guide only 7 of them are available as objects in the datacontext.
If I try to import ONLY the view that gets left out I get an empty model.
Is there some kind of limitation that I dont know of? Or is this a known problem?
Sounds like there is something special with this view. Things to check:
Are the rights the same on this view as others?
Try running a select on this view from query manager to confirm that it works
Open up the "empty" model in an xml view and see if there are any error messages in it
I have ran into issues importing tables and views with no key defined. The entity framework will try to assign one automatically if it can, but if you have duplicate data you may have to create a primary key before EF will bring it in.
That didnt do the trick. I removed all joins from the view definition and added a very simple view (basically just a select from a single table). That worked. Then I added the joins one by one and made the view more complicated for each step. Now I have the same view as I had before I started this process and I can now import it without problems. Something is strange in the state of Denmark