* Added required files to create a snap package. Launchpad account will automate the build whenever code is committed to git repo
# What is a snap?
A snap :
* is a squashFS filesystem containing your app code and a snap.yaml file containing specific metadata. It has a read-only file-system and, once installed, a writable area.
* is self-contained. It bundles most of the libraries and run-times it needs and can be updated and reverted without affecting the rest of the system.
* is confined from the OS and other apps through security mechanisms, but can exchange content and functions with other snaps according to fine-grained policies controlled by the user and the OS defaults.
//TODO
* Try reducing the size of final snap packages by removing unnecessary packages from priming stage
Signed-off-by: Navdeep Singh Sidhu <deepsidhu1313@users.noreply.github.com>
Change the control of the page_size PRAGMA from a spin box to a combo
box in the Edit Pragma tab. This makes sure no values are entered which
aren't a power of two. The same change was done in the Cipher dialog a
while ago for the same reasons.
When loading a project file which changes the foreign_keys or the
case_sensitive_like PRAGMAs while being in the Edit Pragma tab didn't
update the UI accordingly. Only after changing the tab and returning to
the Edit Pragma tab updated the controls.
We allow the user to edit the case_senstive_like PRAGMA via the UI. But
because its state is not saved in the database - just like with the
foreign_key PRAGMA - we should save it in the project file for users who
want to restore the entire environment.
* Allow "getting" and setting case_sensitive_like pragma
In order to allow case insensitive filtering, the pragma
case_sensitive_like is added to the GUI. Given that this pragma cannot be
read, a special SELECT request is made in DBBrowserDB::getPragma for
inferring its value.
See issue #1489.
* Warning in the pragma case_sensitive_like
This pragma has some peculiarities, so it is convenient to warn the user
about it through a tool-tip in the value.
Our procedure for editing tables may involve a drop of the old table
definition. This will trigger the "ON DELETE CASCADE" clauses of the
child tables, leading to unexpected and silent data loss.
Following the procedure described in:
https://www.sqlite.org/lang_altertable.html
we can guarantee that no data is deleted, but at the cost of opening a
new transaction specific for the table modification. The possible pending
changes must be saved before. This is only done when the foreign_keys
pragma is enabled.
See issue #1481
Menu actions that take the user to a dialog, where the action is completed
with some interaction and that could be cancelled, now have ellipsis.
Actions that only open an informative window do no longer have ellipsis.
Title case used in all menu entries.
See issue #1434
- Some actions not directly related to file operations over databases or
projects have been moved from "File" to a new "Tools" top-level menu entry.
Future tools can be added here.
- Preferences moved from "View" to "Edit" (MacOS is supposed to still have
it in the application menu).
See issue #1434
This disables translation for PRAGMA names and values in the Edit Pragma
tab. The values must not be translated when using the current
implementation because they are used as shown for reading and writing
the PRAGMA values. The names could be translated but probably should not
be because they are more fixed name than description of their function.
See issue #1489.
The translation of key sequences must be empty or follow the official Qt
translated names, otherwise the key sequence is not recognised and it will
not work.
The official translation for Shift key is "May" (not "Mayús" or "Mayús.")
See possibly related issue #1491
Add a new menu option for opening an in-memory database. When working on
an in-memory database some menu options are disabled because they only
make sense when the database is also written to disk. I have left the
Write Changes button enabled though because for some actions the current
transaction needs to be committed - even though it's only committed to
memory then.
See issues #335 and #1492.
The application crashed for me when I opeend a database, then switched
to Browse Data tab, added some records there, then created a new empty
database.
Provide a combo box for selecting the field from the list of fields in the
view.
Uncheck the menu option when the user cancels the action.
Escape the primary key in the UPDATE statements since it is not always
rowid (views, without rowid tables) and consequently the name might needed
it.
Following these steps a crash was observed:
1. Browse a Table T in "Browse Data" tab
2. Change to "Database Structure" tab and delete table T
3. Return to "Browse Data" tab
The application crashed because the combo still had the deleted table
value. It was too soon for the updateInsertDeleteRecordButton() call.
Moving it to the end of the method solves the issue.
Following a series of signals after closing the DB the application reaches
SqliteTableModel::isEditable() which isn't prepared for closed databases.
Taking this into account fixes the crash.
This crash seems to have being introduced in 3da520cdd1
In 5fbf5ca1b2 the label of the "Delete
Record" was inadvertently changed to "Delete record". The label is reverted
to the old style for consistency and for restoring coherence of the
translations.
The new Polish translation is changed accordingly.
See issue #1480.
Ctrl+Shift+Click jumps from a foreign key cell to its referenced row in the
other table. It is only exactly one row if we filter for equality. It will
be also faster.
Before running the actual SQL dump we need to determine the total number
of rows in the database in order to show a progress bar. This code
didn't work as expected since the multithreading changes. On the one
hand it would produce occasional error messages in the console and maybe
even crash. On the other hand the resulting value would always be zero
which in turn leads to the progress bar not working. Both issues are
fixed by rewriting the code here.
See issue #1476.
This commit fixes a regression which was introduced in commit
788134eee6 which broke the parsing of row
values.
It also makes sure CHECK expressions are parsed in exactly the same way,
no matter whether they are a column or a table constraint. Before spaces
were added to the query in a different way. The way it was done for
column constaints had also an error were the minus sign of a negative
number was separated from the first digit by a space. This is fixed,
too.
Because of all the changes this commit also adjusts the tests to expect
the new layout of the check expressions. It also adds some new tests for
row values and for complex expressions to make sure both work. Finally,
it also removes all QScintilla dependencies from the tests which don't
seem to be necessary.
When the filter lines have not been generated for a Extended Table
(currently the case for Execute SQL tables), the filter actions make no
sense, so they are disabled.
See issue #1469
This adds support for all operators when applied to string values.
Formerly they were always treated as a Containing (LIKE) operator, but
after the implementation of bbe2e33ea4 the
lack of these operators were more visible and, at least, the omission of
<> seems a bug. But the omission of the others may also be a limitation.
For easing the return to the old behaviour, the Containing filter option
now takes into account the necessity of escaping the value when it starts
by one of the operator characters.
For operators applied to strings the behaviour is documented by Sqlite3
here: https://www.sqlite.org/datatype3.html#collating_sequences
See related issue #1463.
This commit changes the execution logic in the Execute SQL tab. Before
this we were trying to first get the exact part of the SQL text to
execute and then execute it without further checking. After this we're
only trying to find an exact start position for the SQL text to execute
while the end position is only a rough estimate. This way the exact end
position can be determined by SQLite.
This fixes issue #1470.
It also cleans up the code a bit and (hopefully) makes it a bit easier
to read.
- The start and index is only manipulated for the special case of the
start position being at the end of a line (typical when the sentences begin
at the first column. This gives accurate results for both error indicators
and line references in log.
- Tab name in execution titles.
- 'IN' in titles instead of 'AT'.
This fixes parsing of expressions of the form '(x) AND/OR y' and similar
types. It also fixes expression of the '(x)' type and of the '(x op y
AND z op w)' type.
See issue #1454.
