Diffstat (limited to 'libopie/pim/ocontactaccessbackend_sql.cpp') (more/less context) (ignore whitespace changes)
| -rw-r--r-- | libopie/pim/ocontactaccessbackend_sql.cpp | 5 |
1 files changed, 4 insertions, 1 deletions
diff --git a/libopie/pim/ocontactaccessbackend_sql.cpp b/libopie/pim/ocontactaccessbackend_sql.cpp index a5be4c8..d20df56 100644 --- a/libopie/pim/ocontactaccessbackend_sql.cpp +++ b/libopie/pim/ocontactaccessbackend_sql.cpp @@ -1,92 +1,95 @@ /* * SQL Backend for the OPIE-Contact Database. * * Copyright (c) 2002 by Stefan Eilers (Eilers.Stefan@epost.de) * * ===================================================================== * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU Library General Public * License as published by the Free Software Foundation; either * version 2 of the License, or (at your option) any later version. * ===================================================================== * ===================================================================== * Version: $Id$ * ===================================================================== * History: * $Log$ + * Revision 1.5 2004/03/14 13:50:35 alwin + * namespace correction + * * Revision 1.4 2003/12/22 10:19:26 eilers * Finishing implementation of sql-backend for datebook. But I have to * port the PIM datebook application to use it, before I could debug the * whole stuff. * Thus, PIM-Database backend is finished, but highly experimental. And some * parts are still generic. For instance, the "queryByExample()" methods are * not (or not fully) implemented. Todo: custom-entries not stored. * The big show stopper: matchRegExp() (needed by OpieSearch) needs regular * expression search in the database, which is not supported by sqlite ! * Therefore we need either an extended sqlite or a workaround which would * be very slow and memory consuming.. * * Revision 1.3 2003/12/08 15:18:10 eilers * Committing unfinished sql implementation before merging to libopie2 starts.. * * Revision 1.2 2003/09/29 07:44:26 eilers * Improvement of PIM-SQL Databases, but search queries are still limited. * Addressbook: Changed table layout. Now, we just need 1/3 of disk-space. * Todo: Started to add new attributes. Some type conversions missing. * * Revision 1.1 2003/09/22 14:31:16 eilers * Added first experimental incarnation of sql-backend for addressbook. * Some modifications to be able to compile the todo sql-backend. * A lot of changes fill follow... * */ #include "ocontactaccessbackend_sql.h" #include <qarray.h> #include <qdatetime.h> #include <qstringlist.h> #include <qpe/global.h> #include <qpe/recordfields.h> #include <opie/ocontactfields.h> #include <opie/oconversion.h> #include <opie2/osqldriver.h> #include <opie2/osqlresult.h> #include <opie2/osqlmanager.h> #include <opie2/osqlquery.h> - +using namespace Opie::DB; // If defined, we use a horizontal table ( uid, attr1, attr2, attr3, ..., attrn ) instead // vertical like "uid, type, value". // DON'T DEACTIVATE THIS DEFINE IN PRODUCTIVE ENVIRONMENTS !! #define __STORE_HORIZONTAL_ // Distinct loading is not very fast. If I expect that every person has just // one (and always one) 'Last Name', I can request all uid's for existing lastnames, // which is faster.. // But this may not be true for all entries, like company contacts.. // The current AddressBook application handles this problem, but other may not.. (eilers) #define __USE_SUPERFAST_LOADQUERY /* * Implementation of used query types * CREATE query * LOAD query * INSERT * REMOVE * CLEAR */ namespace { /** * CreateQuery for the Todolist Table */ class CreateQuery : public OSQLQuery { public: CreateQuery(); ~CreateQuery(); QString query()const; |