I have a cassadra namespace with a table and a materialized view from it.
A row got deleted in the base table but the change was not propagated to the materialized view. I don't know the exact reason why this happend.
So now I am stuck with that row in the MV and I am not able to delete it.
Any ideas?
Yeah, materialized views are still very much broken. The two main problems are:
There isn't a way to know when a MV is out of sync.
Once it's out of sync, there really isn't a way to get it back in sync.
So it sounds like you're past point #1.
There is a nodetool rebuild_view command, but it does not clear-out existing data, which is what you would need.
Unfortunately, I think the only path forward is to DROP the view and re-create it.
Related
I have a custom service module (myproject-service & myproject-api).
With Liferay 7.2 and previous versions, when I changed my database model (for exemple : add a new column in a table in the service.xml), I used an UpgradeProcess and an UpgradeStepRegistrator, with an incrementation of the Liferay-Require-SchemaVersion.
Since the 7.3 version, the autoupgrade has been moved to a property and changed to false value. In developpement, this value is true and everything works fine but in production, my custom service doesn't upgrade now at server start.
Is there a solution to make this system works again automatically ? I've seen that now we have to do the upgrade manually in the gogo shell with upgrade:execute command.
You are probably looking for
Set this to true to execute the upgrade process when the portal starts and modules are activated.
upgrade.database.auto.run=false
You still need to build the "upgradeProcess", as in:
https://help.liferay.com/hc/en-us/articles/360018162851-Creating-Data-Upgrade-Processes-for-Modules-
Technically, you could activate the same property in production systems. However, this is neither safe, nor performant: The solution for table updates is generic and (as far as I know) will
export your table's data,
DROP TABLE,
CREATE TABLE (with the new structure)
populate the table with the previously saved data.
Now, apart from this being horribly slow for large amounts of data, there are some other shortcomings:
if you have renamed a column, or
added a non-nullable column,
this would fail to do the work as you expected it (even in development).
Further:
If this process is interrupted at any time, you might lose all of your data
In many cases, a simple ALTER TABLE xxx ADD COLUMN yyy would be sufficient, and is quick, safe and easy to do within SQL. That's where your UpgradeProcess kicks in. You wouldn't want to do that after every little bit in development (hence the property), but you certainly don't want to DROP TABLE with important data in production, and wait for who-knows-how-long, when there was just a trivial change.
From that point of view: You want to write a custom UpgradeProcess, even if you don't know that you do. And there's even a great starting point, that takes away the repetitive and low level work.
This seems like a simple question, but Google doesn't seem to want to give me a direct answer.
I've been given an Access 2016 database with some queries that the owner would like his client to use. When a query is run and displays data, the default is that users can make changes to the displayed data and these changes are saved to the underlying table. Is there a way to protect those tables so that they don't change if the user makes changes?
This has the feel of a simple question, but I can't seem to find a way to lock those underlying tables.
You can use Before Change Data Macro as a workaround
Switch table to Design View and create Before Change Macro, like this:
This macro will instantly revert any changes that user make at YourField or AnotherField. You can lock selected columns only, if you wish.
Adding new records is unaffected. For more details see https://msdn.microsoft.com/en-us/library/office/ff835322.aspx
Well, build a report or a continues items form, and have the users launch hat report (or form). If you use a form, then set the edits = no, and your problem is solved.
You might have to change your start-up settings to hide the navigation pane, and hide all queries etc. (but this is quite easy to do).
Thus you provide a menu form, perhaps custom ribbon, or a form hat simply lets the user select the form or report to launch. That way, users can mess around with the actual query, and the resulting report (or form) can be set to not edit data.
Yesterday, the person in charge of adding content to our OrchardCMS website suddenly got this error when trying to access the Content section in the Dashboard and we can't add any new content any more.
I've imported a bacpac of the database in production and started locally debugging. When trying to access the Content an exception is thrown right here:
And, if we look in the database, the Orchard_Framework_ContentItemVersionRecord table contains a duplicated item with the same version Number, both are "latest version" and they both have the same ContentItemRecord_id.
My concern now is how should we fix this without causing any side effect somewhere else, since I don't fully understand how Orchard manages relations between items, parts, and versions.
Solution proposal:
It seems natural and obvious to manually update the "is latest version" of one of the items to false and increment the version number of the latest one.
Is this solution right or will I cause a side problem?
Have you experienced this before?
Do you know if this is caused by a wrong way of defining the model or something I can do to prevent this from happening again?
Quick answer: it is probably due to double clicking the publish button... Small tip and hack: hide publish button on click...
I remember that happened to me once before, it was ugly situation and a lot of debugging had to be done to find the cause.
The only fix I could find back then was to alter/edit/fix the db data manually.
I must ask
did that error happen once or does it happen all the time?
I am in search of an easy way to clear all data logged into core data model. Please note that I don't want this to happen every time the app is opened. I merely need an easy way to clear test data that has been recorded from a text input. Any ideas? Thank you in advance!
You can delete the installed app from the device. This gets rid of all coredata entries and other saved entries.
There is also a programmatic solution mentioned here Clearing CoreData and all that inside
I have a reason to prefer my plugin to be registered on post-op but I'd need to put something in it (change a field to another value). Do I really have to register it on pre-op or can I shove my update into it despite that the operation has been carried out already?
I'd prefer to avoid firing up an update. The code logic might get a bit crowdy and confusing by that, since there'll be a lot of stuff to do upon a "real" update.
Changes made to the target entity in post-op will not end up in the database unless you run an update manually.
You could consider breaking up your plugin into two. One to change the field in pre-op and one to do whatever it is you're doing in post-op.
Plugins can share data: http://msdn.microsoft.com/en-us/library/gg328579.aspx