[Digikam-devel] Update query fails
Gilles Caulier
caulier.gilles at gmail.com
Mon Jun 6 22:02:12 BST 2016
Really ? If this is true, with all ';' we can considerate that nothing can
work previously.
Gilles Caulier
2016-06-06 22:46 GMT+02:00 Swati Lodha <swatilodha27 at gmail.com>:
> The semicolon in SQL is a statement terminator. It specifies that a
> particular statement has ended. This allows more than one statement to be
> executed.
> Missing ; in the queries would thus never execute that query.
>
>
> ᐧ
>
> On Tue, Jun 7, 2016 at 2:10 AM, Gilles Caulier <caulier.gilles at gmail.com>
> wrote:
>
>> There is no V1 and V2 as i know. This is why code is commented (typically
>> a copy and cast from me when i migrate libkface to digiKam core, using
>> other DB class code as template.
>>
>> Gilles Caulier
>>
>> 2016-06-06 22:37 GMT+02:00 Gilles Caulier <caulier.gilles at gmail.com>:
>>
>>> Patch sond fine.
>>>
>>> Q : What' s the side effect to miss ";" at end of sql statements ?
>>>
>>> Gilles Caulier
>>>
>>> 2016-06-05 21:24 GMT+02:00 Swati Lodha <swatilodha27 at gmail.com>:
>>>
>>>> Please find attached patch for facesdb.
>>>>
>>>> Committing on git/master. Compiles without error.
>>>>
>>>> Thank you.
>>>> ᐧ
>>>>
>>>> On Sun, Jun 5, 2016 at 2:38 PM, Swati Lodha <swatilodha27 at gmail.com>
>>>> wrote:
>>>>
>>>>> I've now added #include "digikam_debug.h" under *Local includes *for
>>>>> qCDebug statement.
>>>>>
>>>>> ᐧ
>>>>>
>>>>> On Sun, Jun 5, 2016 at 2:33 PM, Gilles Caulier <
>>>>> caulier.gilles at gmail.com> wrote:
>>>>>
>>>>>> Patch is fine to commit in git/master.
>>>>>>
>>>>>> qCDebug(debug namespace) is the reight way to print statements on the
>>>>>> console. At run time, there are run to enable/disable prints.
>>>>>>
>>>>>> debug namespace are declared in /core/app/utils/digikam_debug.h
>>>>>>
>>>>>> Gilles Caulier
>>>>>>
>>>>>> 2016-06-05 10:44 GMT+02:00 Swati Lodha <swatilodha27 at gmail.com>:
>>>>>>
>>>>>>> Please fnd the attached patch. Two changes made to the thumbsdb.cpp
>>>>>>> file:
>>>>>>>
>>>>>>> 1) Added ";" to the SQL queries.
>>>>>>>
>>>>>>> 2) 2 TODOs were mentioned to check the return status. So I put the
>>>>>>> query state result in qCDebug() to check ithe query state.
>>>>>>> Is this done correctly?
>>>>>>>
>>>>>>> ᐧ
>>>>>>>
>>>>>>> On Sun, Jun 5, 2016 at 12:44 PM, Swati Lodha <swatilodha27 at gmail.com
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> I'll make sure from now on, I make these fixes in master branch.
>>>>>>>> And will also write more precise commit messages.
>>>>>>>>
>>>>>>>> I'll read this page and take a care in future.
>>>>>>>>
>>>>>>>> Thank you.
>>>>>>>>
>>>>>>>> ᐧ
>>>>>>>>
>>>>>>>> On Sun, Jun 5, 2016 at 11:46 AM, Gilles Caulier <
>>>>>>>> caulier.gilles at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Another remark : A fix done in master can be simply synchronized
>>>>>>>>> in your devel branch easily with git. No need to make a new dedicated
>>>>>>>>> commit in your branch. Later, when we merge back your branch to master,
>>>>>>>>> this will be more problematic.
>>>>>>>>>
>>>>>>>>> I explain well in this wiki page :
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://community.kde.org/Digikam/GSoC2014#Branches_Creation_and_Maintenance
>>>>>>>>>
>>>>>>>>> Take a care yo your path in git repository about your devel
>>>>>>>>> banch...
>>>>>>>>>
>>>>>>>>> Gilles Caulier
>>>>>>>>>
>>>>>>>>> 2016-06-05 8:11 GMT+02:00 Gilles Caulier <caulier.gilles at gmail.com
>>>>>>>>> >:
>>>>>>>>>
>>>>>>>>>> The PR ???
>>>>>>>>>>
>>>>>>>>>> I see your commit in your git developpement branch.
>>>>>>>>>>
>>>>>>>>>> I think this simple fixes can be committed directly in git master
>>>>>>>>>> for production. There are no intrusive and do not introduce new feature.
>>>>>>>>>>
>>>>>>>>>> On remark about your commits : make it more atomic as possible.
>>>>>>>>>> Your commit introduce 2 fixes : one for all missing ";" at end of SQL
>>>>>>>>>> statements, one other to fix the mess between image and video metadata DB
>>>>>>>>>> scan.
>>>>>>>>>>
>>>>>>>>>> Gilles Caulier
>>>>>>>>>>
>>>>>>>>>> 2016-06-05 0:46 GMT+02:00 Swati Lodha <swatilodha27 at gmail.com>:
>>>>>>>>>>
>>>>>>>>>>> I've sent the PR. Please review.
>>>>>>>>>>>
>>>>>>>>>>> ᐧ
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Jun 5, 2016 at 3:41 AM, Swati Lodha <
>>>>>>>>>>> swatilodha27 at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Yes.
>>>>>>>>>>>>
>>>>>>>>>>>> I'll commit now. Was waiting for verification.
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you.
>>>>>>>>>>>> ᐧ
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Jun 5, 2016 at 3:39 AM, Gilles Caulier <
>>>>>>>>>>>> caulier.gilles at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> The patch sound good.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Did you have a working ssh connexion now to commit yourself in
>>>>>>>>>>>>> KDE repository ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> `Gilles Caulier
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2016-06-04 20:43 GMT+02:00 Swati Lodha <swatilodha27 at gmail.com
>>>>>>>>>>>>> >:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Final patch for coredb.cpp
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank you.
>>>>>>>>>>>>>> ᐧ
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Jun 3, 2016 at 11:44 PM, Gilles Caulier <
>>>>>>>>>>>>>> caulier.gilles at gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This patch sound fine.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I would to know the Marcel viewpoint here, just to be sure.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Take a care, the patch version 1 is also included in this
>>>>>>>>>>>>>>> one.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Gilles Caulier
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2016-06-02 21:29 GMT+02:00 Swati Lodha <
>>>>>>>>>>>>>>> swatilodha27 at gmail.com>:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Check this patch too.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thank you.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ᐧ
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Fri, Jun 3, 2016 at 12:37 AM, Swati Lodha <
>>>>>>>>>>>>>>>> swatilodha27 at gmail.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Please check this patch.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Sorry for inconvenience.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ᐧ
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Thu, Jun 2, 2016 at 11:56 PM, Swati Lodha <
>>>>>>>>>>>>>>>>> swatilodha27 at gmail.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Please find attached patch file for the same.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thank you.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ᐧ
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Thu, Jun 2, 2016 at 8:57 PM, Swati Lodha <
>>>>>>>>>>>>>>>>>> swatilodha27 at gmail.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hello
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> In coredb.cpp:4547 ";" is missing after the UPDATE
>>>>>>>>>>>>>>>>>>> query. This change should be committed?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>> ᐧ
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Wed, Jun 1, 2016 at 6:14 PM, Richard Mortimer <
>>>>>>>>>>>>>>>>>>> richm+digikam at oldelvet.org.uk> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 01/06/2016 10:12, Swati Lodha wrote:
>>>>>>>>>>>>>>>>>>>> > I understand this now. Thank you for clarification.
>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>> > So as it mentioned around coredb.cpp:549
>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>> > 549 // We need to work around the table
>>>>>>>>>>>>>>>>>>>> constraint, no we want to
>>>>>>>>>>>>>>>>>>>> > delete older stale albums with
>>>>>>>>>>>>>>>>>>>> > 550 // the same relativePath, and adjust
>>>>>>>>>>>>>>>>>>>> relativePaths depending on
>>>>>>>>>>>>>>>>>>>> > albumRoot.
>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>> > I think that this needs to be done?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It is all part of the bigger picture that needs
>>>>>>>>>>>>>>>>>>>> considering to allow
>>>>>>>>>>>>>>>>>>>> referential integrity to be applied across the (MySQL)
>>>>>>>>>>>>>>>>>>>> database. I don't
>>>>>>>>>>>>>>>>>>>> have the years of experience with digikam that Marcel
>>>>>>>>>>>>>>>>>>>> does but I think
>>>>>>>>>>>>>>>>>>>> the following is required:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 1 - apply "ideal" referential integrity to the MySQL
>>>>>>>>>>>>>>>>>>>> digikam schema
>>>>>>>>>>>>>>>>>>>> (mostly done).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2 - now identify where things break down due to
>>>>>>>>>>>>>>>>>>>> interaction with the
>>>>>>>>>>>>>>>>>>>> outside world (file systems, other photo
>>>>>>>>>>>>>>>>>>>> editors/tools). Generally I
>>>>>>>>>>>>>>>>>>>> think this is easy to spot and is normally the root of
>>>>>>>>>>>>>>>>>>>> an information
>>>>>>>>>>>>>>>>>>>> hierarchy. (tags tree, albums, album roots spring to
>>>>>>>>>>>>>>>>>>>> mind).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I think that digikam has been pretty consistent with
>>>>>>>>>>>>>>>>>>>> using a magic "0"
>>>>>>>>>>>>>>>>>>>> value to represent where something no-longer fits into
>>>>>>>>>>>>>>>>>>>> a hierarchy but
>>>>>>>>>>>>>>>>>>>> is likely to re-appear in due course.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 3 - Once identified the architectural decision is how
>>>>>>>>>>>>>>>>>>>> to handle it in a
>>>>>>>>>>>>>>>>>>>> database configured to enforce referential integrity.
>>>>>>>>>>>>>>>>>>>> Bear in mind that
>>>>>>>>>>>>>>>>>>>> this needs to continue to support SQLite too without
>>>>>>>>>>>>>>>>>>>> having to add too
>>>>>>>>>>>>>>>>>>>> many special cases. Note that SQLite is capable of
>>>>>>>>>>>>>>>>>>>> supporting
>>>>>>>>>>>>>>>>>>>> referential integrity so the choice may be to adopt the
>>>>>>>>>>>>>>>>>>>> same solution
>>>>>>>>>>>>>>>>>>>> for both.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Really the choices for handling the orphaned items are:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> a - disable referential integrity on those affected
>>>>>>>>>>>>>>>>>>>> fields. That is
>>>>>>>>>>>>>>>>>>>> almost trivial to implement but does negate some of the
>>>>>>>>>>>>>>>>>>>> benefits.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> b - add "special" internal rows that can be used to
>>>>>>>>>>>>>>>>>>>> collect these
>>>>>>>>>>>>>>>>>>>> temporarily orphaned nodes. I know that there is one at
>>>>>>>>>>>>>>>>>>>> the root of the
>>>>>>>>>>>>>>>>>>>> tags tree for MySQL. Note they are a bit tricky to
>>>>>>>>>>>>>>>>>>>> arrange because they
>>>>>>>>>>>>>>>>>>>> really need to be created with a primary key of zero to
>>>>>>>>>>>>>>>>>>>> match the
>>>>>>>>>>>>>>>>>>>> existing behaviour of putting zero in there.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> c - change to use null instead of a magic placeholder
>>>>>>>>>>>>>>>>>>>> value. That is
>>>>>>>>>>>>>>>>>>>> probably a purer solution but does create differences
>>>>>>>>>>>>>>>>>>>> between SQLite and
>>>>>>>>>>>>>>>>>>>> MySQL.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I'd probably suggest that option b is the right one to
>>>>>>>>>>>>>>>>>>>> minimise chances
>>>>>>>>>>>>>>>>>>>> of short/medium term breakage but would be interested
>>>>>>>>>>>>>>>>>>>> to know what
>>>>>>>>>>>>>>>>>>>> others think.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Richard
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> P.S. even if b & c are chosen there are some potential
>>>>>>>>>>>>>>>>>>>> issues that may
>>>>>>>>>>>>>>>>>>>> occur if multiple orphaned tags, folders, images have
>>>>>>>>>>>>>>>>>>>> the same name.
>>>>>>>>>>>>>>>>>>>> That will trip up with existing "unique" constraints on
>>>>>>>>>>>>>>>>>>>> the database. I
>>>>>>>>>>>>>>>>>>>> suspect that this should just be left as "good enough"
>>>>>>>>>>>>>>>>>>>> for now.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>> > Regards
>>>>>>>>>>>>>>>>>>>> > ᐧ
>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>> > On Wed, Jun 1, 2016 at 2:28 PM, Marcel Wiesweg <
>>>>>>>>>>>>>>>>>>>> marcel.wiesweg at gmx.de
>>>>>>>>>>>>>>>>>>>> > <mailto:marcel.wiesweg at gmx.de>> wrote:
>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>> > Have a look at the (rather complex)
>>>>>>>>>>>>>>>>>>>> CollectionScanner.
>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>> > The problem is the nature of our scan, which will
>>>>>>>>>>>>>>>>>>>> always run in all
>>>>>>>>>>>>>>>>>>>> > kinds of
>>>>>>>>>>>>>>>>>>>> > race conditions with the file system.
>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>> > When a folder is moved, we may notice that it is
>>>>>>>>>>>>>>>>>>>> removed at the previous
>>>>>>>>>>>>>>>>>>>> > location. Later, we see it appear at the new
>>>>>>>>>>>>>>>>>>>> location. It would be
>>>>>>>>>>>>>>>>>>>> > unfortunate
>>>>>>>>>>>>>>>>>>>> > to have completely deleted all album metadata in
>>>>>>>>>>>>>>>>>>>> the meantime.
>>>>>>>>>>>>>>>>>>>> > Therefore, it
>>>>>>>>>>>>>>>>>>>> > is made a stale album, which can be resurrected
>>>>>>>>>>>>>>>>>>>> later if a new place
>>>>>>>>>>>>>>>>>>>> > can be
>>>>>>>>>>>>>>>>>>>> > identified.
>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>> > This is done in a similar way for images. Here,
>>>>>>>>>>>>>>>>>>>> we can identify them by
>>>>>>>>>>>>>>>>>>>> > content, so the storage of "removed" images is
>>>>>>>>>>>>>>>>>>>> even more extensively
>>>>>>>>>>>>>>>>>>>> > done.
>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>> > > This query is executed in
>>>>>>>>>>>>>>>>>>>> core/libs/database/coredb.cpp:576 in the function
>>>>>>>>>>>>>>>>>>>> > > to create stale Albums, that is why the
>>>>>>>>>>>>>>>>>>>> albumRoot has been set to 0.
>>>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>>>> > > I would like to ask why is there a need to
>>>>>>>>>>>>>>>>>>>> create the stale Albums?
>>>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>>>> > > Regards
>>>>>>>>>>>>>>>>>>>> > > ᐧ
>>>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>>>> > > On Wed, Jun 1, 2016 at 1:19 AM, Marcel Wiesweg
>>>>>>>>>>>>>>>>>>>> > <marcel.wiesweg at gmx.de <mailto:
>>>>>>>>>>>>>>>>>>>> marcel.wiesweg at gmx.de>>
>>>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>>>> > > wrote:
>>>>>>>>>>>>>>>>>>>> > > > Please check the context where it is called,
>>>>>>>>>>>>>>>>>>>> but I am quite sure
>>>>>>>>>>>>>>>>>>>> > that
>>>>>>>>>>>>>>>>>>>> > > > there is
>>>>>>>>>>>>>>>>>>>> > > > a special meaning in setting album root to 0.
>>>>>>>>>>>>>>>>>>>> > > > I'm sure there is a similar case with deleted
>>>>>>>>>>>>>>>>>>>> images where album
>>>>>>>>>>>>>>>>>>>> > is set to
>>>>>>>>>>>>>>>>>>>> > > > 0,
>>>>>>>>>>>>>>>>>>>> > > > but the entry is preserved in case the image
>>>>>>>>>>>>>>>>>>>> reappears at a
>>>>>>>>>>>>>>>>>>>> > different
>>>>>>>>>>>>>>>>>>>> > > > place
>>>>>>>>>>>>>>>>>>>> > > > (moving files where the removal is noticed
>>>>>>>>>>>>>>>>>>>> first)
>>>>>>>>>>>>>>>>>>>> > > >
>>>>>>>>>>>>>>>>>>>> > > > Marcel
>>>>>>>>>>>>>>>>>>>> > > >
>>>>>>>>>>>>>>>>>>>> > > > > Hello.
>>>>>>>>>>>>>>>>>>>> > > > >
>>>>>>>>>>>>>>>>>>>> > > > > I was facing this error from past few days:
>>>>>>>>>>>>>>>>>>>> > > > >
>>>>>>>>>>>>>>>>>>>> > > > > MariaDB [digikam]> update Albums set
>>>>>>>>>>>>>>>>>>>> albumRoot=0 where id=10;
>>>>>>>>>>>>>>>>>>>> > > > >
>>>>>>>>>>>>>>>>>>>> > > > > > ERROR 1452 (23000): Cannot add or update
>>>>>>>>>>>>>>>>>>>> a child row: a
>>>>>>>>>>>>>>>>>>>> > foreign key
>>>>>>>>>>>>>>>>>>>> > > > > > constraint fails (`digikam`.`Albums`,
>>>>>>>>>>>>>>>>>>>> CONSTRAINT
>>>>>>>>>>>>>>>>>>>> > `Albums_AlbumRoot
>>>>>>>>>>>>>>>>>>>> > > > > > s` FOREIGN KEY (`albumRoot`) REFERENCES
>>>>>>>>>>>>>>>>>>>> `AlbumRoots` (`id`)
>>>>>>>>>>>>>>>>>>>> > ON DELETE
>>>>>>>>>>>>>>>>>>>> > > > > > CASCADE ON UPDATE CASCADE)
>>>>>>>>>>>>>>>>>>>> > > > >
>>>>>>>>>>>>>>>>>>>> > > > > I figured out that as 'id' is AlbumRoots
>>>>>>>>>>>>>>>>>>>> table is not 0. So
>>>>>>>>>>>>>>>>>>>> > 'albumRoot'
>>>>>>>>>>>>>>>>>>>> > > >
>>>>>>>>>>>>>>>>>>>> > > > in
>>>>>>>>>>>>>>>>>>>> > > >
>>>>>>>>>>>>>>>>>>>> > > > > Images table can't be set to 0. This is I
>>>>>>>>>>>>>>>>>>>> think the possible
>>>>>>>>>>>>>>>>>>>> > reason for
>>>>>>>>>>>>>>>>>>>> > > >
>>>>>>>>>>>>>>>>>>>> > > > FK
>>>>>>>>>>>>>>>>>>>> > > >
>>>>>>>>>>>>>>>>>>>> > > > > constraint failing.
>>>>>>>>>>>>>>>>>>>> > > > >
>>>>>>>>>>>>>>>>>>>> > > > > I used this statement instead & it worked:
>>>>>>>>>>>>>>>>>>>> > > > >
>>>>>>>>>>>>>>>>>>>> > > > > MariaDB [digikam]> update Albums set
>>>>>>>>>>>>>>>>>>>> albumRoot=1 where id=10;
>>>>>>>>>>>>>>>>>>>> > > > >
>>>>>>>>>>>>>>>>>>>> > > > > > Query OK, 0 rows affected (0.06 sec)
>>>>>>>>>>>>>>>>>>>> > > > > > Rows matched: 1 Changed: 0 Warnings: 0
>>>>>>>>>>>>>>>>>>>> > > > >
>>>>>>>>>>>>>>>>>>>> > > > > Please look into this.
>>>>>>>>>>>>>>>>>>>> > > > >
>>>>>>>>>>>>>>>>>>>> > > > > Regards
>>>>>>>>>>>>>>>>>>>> > > > > ᐧ
>>>>>>>>>>>>>>>>>>>> > > >
>>>>>>>>>>>>>>>>>>>> > > >
>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>> > > > Digikam-devel mailing list
>>>>>>>>>>>>>>>>>>>> > > > Digikam-devel at kde.org <mailto:
>>>>>>>>>>>>>>>>>>>> Digikam-devel at kde.org>
>>>>>>>>>>>>>>>>>>>> > > >
>>>>>>>>>>>>>>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-devel
>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>> > _______________________________________________
>>>>>>>>>>>>>>>>>>>> > Digikam-devel mailing list
>>>>>>>>>>>>>>>>>>>> > Digikam-devel at kde.org <mailto:
>>>>>>>>>>>>>>>>>>>> Digikam-devel at kde.org>
>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-devel
>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>> > _______________________________________________
>>>>>>>>>>>>>>>>>>>> > Digikam-devel mailing list
>>>>>>>>>>>>>>>>>>>> > Digikam-devel at kde.org
>>>>>>>>>>>>>>>>>>>> > https://mail.kde.org/mailman/listinfo/digikam-devel
>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>> Digikam-devel mailing list
>>>>>>>>>>>>>>>>>>>> Digikam-devel at kde.org
>>>>>>>>>>>>>>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-devel
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> Digikam-devel mailing list
>>>>>>>>>>>>>>>> Digikam-devel at kde.org
>>>>>>>>>>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-devel
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> Digikam-devel mailing list
>>>>>>>>>>>>>>> Digikam-devel at kde.org
>>>>>>>>>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-devel
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> Digikam-devel mailing list
>>>>>>>>>>>>>> Digikam-devel at kde.org
>>>>>>>>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-devel
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Digikam-devel mailing list
>>>>>>>>>>>>> Digikam-devel at kde.org
>>>>>>>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-devel
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Digikam-devel mailing list
>>>>>>>>>>> Digikam-devel at kde.org
>>>>>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-devel
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Digikam-devel mailing list
>>>>>>>>> Digikam-devel at kde.org
>>>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-devel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Digikam-devel mailing list
>>>>>>> Digikam-devel at kde.org
>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-devel
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Digikam-devel mailing list
>>>>>> Digikam-devel at kde.org
>>>>>> https://mail.kde.org/mailman/listinfo/digikam-devel
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Digikam-devel mailing list
>>>> Digikam-devel at kde.org
>>>> https://mail.kde.org/mailman/listinfo/digikam-devel
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Digikam-devel mailing list
>> Digikam-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/digikam-devel
>>
>>
>
> _______________________________________________
> Digikam-devel mailing list
> Digikam-devel at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20160606/40f72a9a/attachment.html>
More information about the Digikam-devel
mailing list