Is there a built-in delete function in XQuery that I can use to delete the actual file in the database in a certain directory say a/b/c/d.xml
How to implement one if there is no such function?
Deleting a document is implementation dependent. In MarkLogic Server, you would do this:
xdmp:document-delete("a/b/c/d.xml")
I realize that this question was posted nearly a year and a half ago, but I thought this would be a helpful contribution.
If you just want to delete a node, you can use this:
xdmp:node-delete(/parentNode/childNode)
The childNode would be deleted.
See this link
In Zorba and BaseX you would do file:remove("a/b/c/d.xml") (there are also other processors supporting this module, please add)
Related
I don't want to provide a migration script while changing table schema in realm java. Also, app should not crash and all the previous data should be erased or truncated something similar to fallbackToDestructiveMigration() as room dose?
Realm provides RealmConfiguration.Builder().deleteIfMigrationNeeded()..., where deleteIfMigrationNeeded() does exactly what you are looking for.
I'm working on a sniff for PHP_CodeSniffer 3.x. For example, the class declaration class NoInlineFullyQualifiedClassNameUnitTestInc extends \PSR2R\Base\AbstractBase should be split into a uses and class AbstractBase. The sniff detects similar issues for method signatures.
I believe the problem is that I'm generating and inserting multiple use statements at the same line (i.e., same token), but doing so in separate fixer->beginChangeset() ... fixer->endChangeset() sequences. The fixer treats multiple sets of changes to the same token as a conflict, and things get messy (and wrong).
The GitHub issue is here: https://github.com/php-fig-rectified/psr2r-sniffer/issues/9
Has anyone figured out how to do this writing custom sniffs for the latest 3.x CodeSniffer?
You can also use SlevomatCodingStandard\Sniffs\Namespaces\ReferenceUsedNamesOnlySniff
It turns this
Into this
How to use it?
The best is to use it with EasyCodingStandard like this:
# easy-coding-standard.neon
checkers:
- SlevomatCodingStandard\Sniffs\Namespaces\ReferenceUsedNamesOnlySniff
Install it:
composer require --dev symplify\easy-coding-standard
Run it:
vendor/bin/ecs check src
Fix it:
vendor/bin/ecs check src --fix
Enjoy and let me know how it works for you.
If any troubles come up, just create an issue here. I'm happy to improve this tool as much as possible.
The problem is multiple Sniffer (fixer) changesets editing the same token. I was able to get the Sniff to work by collecting a list of USE statements and inserting them at the end of the Sniff's processing.
I identified the end of processing by searching backwards from the last token to find the first token of the list of registered tokens.
Edit: Here is the sniff: https://github.com/php-fig-rectified/psr2r-sniffer/blob/master/PSR2R/Sniffs/Namespaces/NoInlineFullyQualifiedClassNameSniff.php
Is there any quick and easy way to get all created / programmed objects of a specific developer?
I often search something that i programmed a while ago and i want to save the time.
Greetz, Orangeman
If you don't have version control active, you can query the UtilElements table. For example:
http://www.jaestevan.com/ax-tip-exportar-lista-de-proyectos-en-microsoft-dynamics-ax
I need to write single lines to a file placed on a file server. I am considering utilizing SQLite to ensure that the writing of the line was successful and not just partially completed. However, as insert performance is really essential. My question is, what is the exact process (as it read this, write that, read this and so on) that SQLite goes through when it inserts a row to a table. The table does not have any indexes, nor primary keys, constraints or anything.
This is the most common bottleneck in my experience:
http://www.sqlite.org/faq.html#q19
Except for that, SQLite is really fast. :)
You should use transactions and thus try to avoid fsync()-ing on every INSERT. Take a look here for some benchmarks.
Also, be sure to properly set the two important pragmas:
synchronous (NORMAL)
journal_mode (WAL)
you can use explain for details what happens when you execute a statement: http://www.sqlite.org/lang_explain.html
As title, possible? I have by accident deleted another record due to my ugly html interface in FireFox. The bad thing is this record delete is a root folder which the program automatically cascade delete everything :(
Take a look at undark. I already used it. It it can export the rows (deleted or not) from a SQLite db file if the records were not overwritten. Last version here.
The SQLite-Deleted-Records-Parser does not give the same type of output, but can be useful.
And there are also some products like the SQLite Forensic Explorer, SQLite Repair, Sqlite Database Recovery and SQLiteDoctor.
If you are a developer you can avoid having the same problem again using litereplica. It adds single-master replication to SQLite.
But remember to enable the point-in-time recovery because as the transactions are replicated to the replicas an accidental command like DROP TABLE or DELETE FROM will also be replicated. With PITR you will be able to go to a previous point-in-time.
Or use the Backup API regularly. Although it transfers the entire db on each backup.
And remember: if you copy an SQLite file or use a regular backup approach while a transaction is active
the copy can be corrupted.
Sorry -- nope. Backups are the only option I know of.
In the future, consider never issuing DELETE queries, especially from user-accessible forms (let only the DB admin do it, if anyone) -- just include a field in your tables that marks a record as inactive and then factor that in to your queries in the WHERE clause.
Unfortunately I don't know of a way, either. However, until you do a VACUUM on the SQLite database file the deleted data is generally not technically removed. Perhaps you might be able to still recover some of the data using some sort of hex editor on the file.
It might be possible to go in and see the data via a hex-editor. The only info I could find said that metadata was gone so the records weren't going to come back, but the data itself might still be there. It has a lot to do with how important the data is, I suspect it's not important enough for you to dig out a hex editor.
The data isn't always removed from the file straightaway. If there's lots of it and you're desperate, you could use the UNIX command strings on the file. This may help you to recover various bits and pieces of human-readable data, but it'll be a hard and inaccurate process.
No way. Without a working backup you won't be able to restore this.