connexion base de données SQLite direct ou via ORM (swift3)[réglé]

toolsDev · janvier 2017

Bonjour à toutes et tous,

Je souhaiterais me faire un petit projet d'apprentissage avec le langage swift 3 et une connexion à une base de données embarquée SQLite3

Pour avoir un projet/template propre et adoubé "apple" que me conseilleriez vous ?

j'aimerais le plus possible une couche d'abstraction suffisante pour la réutilisation du code/classes dans d'autres projets ayant le même besoin.

On m'a parlé de CoreData et pas forcément en bien, je pensais qu'un ORM serait parfait à ma demande, mais je vois que les avis divergent sur ce point.

Mon souci, étant bien sur une totale maà®trise sur mes requêtes SQL.

Merci (et au passage bonne et heureuse année 2017 )

xyloweb · janvier 2017

sans aucune hésitation CoreData avec un framework comme JSQCoreDataKit

toolsDev · janvier 2017

salut xyloweb,

merci pour ton retour, j'irais voir ce que propose JSQ CoreData Kit.

Mais visiblement c'est CoreData ? donc, pas la main sur les requêtes, si ?

Pour le moment on m'a conseillé GRDB.swif, je vais testé ça avec un petit projet.

Donc, je suis toujours ouvert à autre chose, du moment que c'est cool à utiliser et à "validé"

Céroce · janvier 2017

Nous en avons déjà parlé en privé, mais ma position est que Core Data est mort dans le coe“ur des développeurs iOS. Comme je l'expliquais, à FrenchKit, l'un des présentateurs a demandé qui avait travaillé avec Core Data et en était revenu, et les 3/4 de la salle ont levé la main.

CoreData est complexe et compliquée, est très difficile voire impossible à déboguer. Elle n'a pas été pensée pour les accès concurrents: même à l'époque où elle a été créée, ça semblait déjà une limitation. Rien que son système de migration est une bonne raison de l'éviter.

Personnellement, je pense que si on veut utiliser CoreData pour faire un cache des requêtes réseau, pourquoi pas, mais pas guère plus. En outre CoreData n'est même pas une option pour du multiplateforme.

Aujourd'hui, la tendance c'est d'utiliser un stockage distant, et c'est Realm qui est la solution la plus séduisante.

Céroce · janvier 2017

On m'a parlé de CoreData et pas forcément en bien, je pensais qu'un ORM serait parfait à ma demande, mais je vois que les avis divergent sur ce point.

Le principe des ORM est discutable en soi: forcer le paradigme objet à s'adapter au paradigme BdD relationnelles.

Mais CoreData est une ORM qui ne s'assume pas. Jamais la doc Apple ne parle d'ORM, mais dit toujours "Vous pouvez aussi utiliser d'autres stockages, comme du XML (mais attention, pour déboguer, seulement, hein), voire créer votre propre format (y'en a qui ont essayé)".

En pratique, quand CoreData est inefficace ou qu'on ne comprend pas ce qu'il fout, en aimerait avoir accès au SQL, mais on ne peut pas. À comparer à Active Record offert par Ruby on Rails.

LeChatNoir · janvier 2017

Je viens "mitiger" un peu ton propos Céroce car le stockage distant, c'est bien mais quand t'as pas de connexion, c'est moins bien... ÂµDans ce cas, CoreData est encore valable.

Après, CoreData ou SqlLite, effectivement, on peut se poser la question.

Tof · janvier 2017

Personnellement je n'utilise pas Core Data. L'expérience que j'en ai est assez proche de @Céroce.

Quand j'ai besoin d'une base de donné en locale sur l'iPhone je vais soit sur Sqlite, soit sur Realm. Realm propose un SDK simple à utiliser et est sans doute plus facile à utiliser pour un débutant. J'adore aussi Sqlite mais sur iOS y a pas de framework officiel. On attaque soit l'API C directement (ex: SQLite Tutorial: Getting Started) soit on passe par un des composants opensource qui existe (SwiftDB, GRDB.swift, SQLite.swift ).

Si la base locale devient vraiment volumineuse il faut se poser la question de savoir si c'est vraiment une bonne idée de tous stocker sur l'iPhone. Il faut pas oublier qu'un iPhone n'a pas pour vocation ni la puissance d'un ordinateur de bureau. Tous mettre sur un serveur peut être tentant mais on perd le mode déconnecté. Construire un système qui mixte à la fois une base locale et une base sur un serveur est difficile à mettre en place si on doit le faire soit-même et n'est pas à la porté d'un débutant. Le mieux est sans doute de regarder du coté de solutions comme Realm Mobile Platform. Cette solution est encore jeune mais le concept est vraiment intéressant. Mon seul regret vis à vis de cette solution c'est qu'ils auraient pu faire la partie serveur en Swift 3 avec Vapor par exemple. Présentement c'est du Node.js et le noyau est en C++. Si vous connaissez une autre solution fullstack en Swift dites le ça m'intéresse

iLandes · janvier 2017

Personnellement je me pose de plus en plus de question sur SQL en général. Le noSQL comme sure Firebase et cloudkit semble avoir le vent en poupe. Firebase par exemple gère très bien les problème de connection. Quand à cloudkit il garantie une partie privé à l'utilisateur et une partie public. En plus (vu au dernier cocoahead à Paris) il y a un type Location qui gère les requêtes liées à tout ce qui est positionnement.

Du coup pour mon projet en cours j'hésite entre realm et cloudkit ...

toolsDev · janvier 2017

bonjour à tous

Vos réponses me créer plus d'interrogations qu'autre chose. En effet, je vois que les outils proposés par apple ne sont pas des plus appréciés (après, selon le contexte tout à une utilité, j'en suis conscient)

Mais pour ma part, un débutant IOS, qui souhaite développer proprement, vous comprendrez que tout ceci est vraiment compliqué ! Avec Java tout est si simple... au regard de toutes vos réponses je suis complètement largué !

Dans mon cas, je souhaite "juste" me connecté sur ma base SQLite3 embarquer et parfois (vraiment plus tard dans mon développement) faire une synchronisation sur une base MySQL via je pense un web service.

Du coup, ce que Céroce m'a proposé me semble viable, c'est-à -dire soit GRDB.swift, soit realm.io

Je vous demande la façon la plus simple pour ensuite une fois la "base" acquise passer à plus complexe.

Ce que je ne comprends pas aussi, est que d'origine apple ne proposerais même pas d'objet pour ce connecté à une base SQLite3 ? Tout ce passe d'après vous retour via des librairies externes... Rien de natif ?

En tout cas merci pour ce super débat, très constructif :-*

Edit :

Je vous rappelle aussi que je cherche un outil sous swift 3 Xcode 8 IOS 10(donc récent) j'ai bien-sur déjà trouvé beaucoup d'API ou autres, mais beaucoup sont déjà dépassés...

Et qu'elle jungle

Edit 2:

J'adore aussi Sqlite mais sur iOS y a pas de framework officiel. On attaque soit l'API C directement (ex: SQLite Tutorial: Getting Started)

la classe COpaquePointer ne fonctionne pas quand je teste le tuto, il est encore dépassé :

Note: Updated for Xcode 7.3, iOS 9.3, and Swift 2.2 on 04-06-2016

C'est bien ça le soucis, c'est vraiment très confus pour trouvé du récent...

LeChatNoir · janvier 2017

Contrairement à Android qui fait du java depuis le début et qui est juste passé de Eclipse à Android Studio pour son outils de dev, Apple a changé bcp de choses ces derniers temps.

Entre les Storyboard, les auto-layout et maintenant un nouveau langage (swift), il faut suivre et s'adapter.

Du coup, les ressources que tu peux trouver en ligne doivent etre remises dans leur contexte et il faut effectivement avoir l'habitude pour détecter l'époque et déterminer si le tutto ou la ressource est tjs "valable" à l'heure actuelle.

Mais pour revenir à ta question initiale, pars sur du swift (ça, c'est sur) et ensuite, il te faut choisir entre CoreData (tout à fait acceptable avec un framework qui te dégrossi), SqlLite (même si y a rien de natif, y a des tas de bibliothèques qui vont bien) ou un service dans le nuage (CloudKit, Firebase, Realm pour ne citer que les plus connus de moi ))

A savoir que ces derniers permettent de gérer une base en local sur le device.

toolsDev · janvier 2017

M'adapter je le fais déjà , ce n'est pas le soucis, mais avoue quand même que Apple n'arrange rien ...

Tout ça pour te dire que je n'attends pas du tout cuit, je demande seulement qu'on me donne une direction, un sens...

C'est vraiment la jungle, quand tu ne connais pas, comment savoir si tel ou tel chose est dépréciée ou carrément plus fonctionnel ?

En testant tu vas me répondre, oui surement, mais le temps investi est considérable ! Voilà le but de mon poste sur ce forum d'entre aide.

J'ai installé cocoapods pour me simplifier l'intégration de ces nouvelles ressources, encore fallait-il savoir que cela existait... Je suis tombé dessus par hasard. C'est le "Composer" du monde apple.

quand on voit toutes les ressources disponibles, oui, cela déroute énormément, quand tu proviens d'un autre langage... tout ça pour UNIQUEMENT ce connecté à une base de données.

LeChatNoir · janvier 2017

Après, il faut avouer que c'était les pionniers et que donc, ils ont pas mal "défriché" (pour Joanna celui là ). Et c'est donc normal que tout ça évolue.

Mais j'avoue que le changement de langage, c'est un peu rude... Une évolution d'Objective-C avec rétrocompatibilité aurait été préférable à mon sens...

toolsDev · janvier 2017

et bien après avoir tester :

GRDB.swift

SQLite.swift (je lui redonne une chance, je re teste)

verdict, les 2 projets ne fonctionnent pas et contiennent un objet déprécié, sqlite3_trace (remplacer par sqlite3_trace_V2 ça ne fonctionne toujours pas, pire ça crash, ben, oui il attends 4 arguments et le code en implémente que 2 et les remplacer par "nil" ne fonctionne pas non plus.

J'ai tout installé via cocoapods, je ne peut m'être planté à ce point...

ça compile bien mais aucun simulateur ne s'affiche.

La documentation indique des imports qui ne fonctionne pas(GRDS), bref, si même la doc est plus à jour là moi je fait comment ...

donc sans passé par FMDB (donc objective-c, ce que je refuse) rien ne marche pour moi, super...

Edit :

et là je découvre que Realm.io est aussi obsolète, la version la plus récente étant Realm Swift 2.3.0

Nickel en fait !

Donc, pour résumé avec swift 3 je ne peut pas me connecter à une base de données SQLite, incroyable, après faut pas me dire que c'est simple hein...

Edit 2 :

Bon j'ai fait mon choix, SQLite.swift mal gré les erreurs dans la documentation et autre pièges disséminés à droite et à gauche je m'en sort... je considère donc mon post clôt concernant mon choix. je verrais une fois plus à l'aise si je part dans l'aventure "ORM"

Merci à tous !

iLandes · janvier 2017

L'avantage de Swift c'est que par essence c'est du récent. Dans google je cherche toujours en commençant ma requête par Swift 3 et j'utilise le filtre par date pour limiter ma recherche à un an maxi. Systématiquement sur n'importe quel source (stack ou cocoapod) je commence par regarder la date de parution.

Le problème est plus large que le seul monde Apple. L'internet vieilli et les informations qu'il contient aussi.

En règle générale quand tu vois une information qui date de 2011, passe ton chemin ;-)

toolsDev · janvier 2017

merci pour ton retour,

Mais j'effectue les mêmes recherches que toi, je sais chercher, dans notre métier/passion cela est un indispensable !

C'est bien pour ça que plus haut, je dis que tout est déprécié, voir même erroné !

groue · janvier 2017

et bien après avoir tester :

GRDB.swift

SQLite.swift (je lui redonne une chance, je re teste)

verdict, les 2 projets ne fonctionnent pas et contiennent un objet déprécié, sqlite3_trace (remplacer par sqlite3_trace_V2 ça ne fonctionne toujours pas, pire ça crash, ben, oui il attends 4 arguments et le code en implémente que 2 et les remplacer par "nil" ne fonctionne pas non plus.

Salut,

Même si tu as fait ton choix et décidé d'utiliser SQLite.swift, je suis étonné que GRDB ne t'ai pas donné satisfaction.

La méthode sqlite3_trace est certes dépréciée, mais dépréciation ne signifie pas qu'elle ne fonctionne plus. GRDB ne peut pas utiliser sqlite_trace_v2 comme ça juste pour faire joli, car c'est une bibliothèque un minimum sérieuse qui ne veut pas casser ses utilisateurs qui font tourner leurs applis sur iOS 8 (où sqlite_trace_v2 n'est pas encore arrivée). sqlite3_trace fonctionne très bien, et c'est tout ce qu'on lui demande.

Quant aux crashes... Je ne sais pas. GRDB fonctionne sans heurt sur de nombreuses applications. Peut-être pourras-tu t'en ouvrir aux développeurs la prochaine fois que tu as des difficultés à intégrer leur travail : http://github.com/groue/GRDB.swift/issues

En général, en tout cas pour GRDB, ça donne de bons résultats : il y a déjà plein de questions qui ont trouvé leurs réponses (https://github.com/groue/GRDB.swift/issues?q=is%3Aclosed).

toolsDev · janvier 2017

Bonjour Groue,

le soucis étant que je développe sous swift 3, petit détail qui à son importance ! Toutes ces librairies fonctionnent, mais pas sous la dernière version de swift visiblement, sauf erreur de ma part, mais mon projet étant créé avec cocoapods, je ne peux me tromper, tout étant automatique.

Larme · janvier 2017

Bonjour Groue,

le soucis étant que je développe sous swift 3, petit détail qui à son importance ! Toutes ces librairies fonctionnent, mais pas sous la dernière version de swift visiblement, sauf erreur de ma part, mais mon projet étant créé avec cocoapods, je ne peux me tromper, tout étant automatique.

Alors :

Pour GRDB, c'est indiqué :

Requirements: iOS 8.0+ / OSX 10.9+ / watchOS 2.0+ â€¢ Xcode 8.1+ â€¢ Swift 3

Swift 2.2: use the version 0.80.2

Swift 2.3: use the version 0.81.2

Swift 3.1 and Xcode 8.3 beta: use the Xcode8.3beta branch

Pour avoir une branche spécifique pour un pod, c'est dans la doc de CocoaPods.

Il suffit de faire



pod 'monPod', :branch => 'nomDeLaBranche'

Dans ton cas, je suppose que ça serait



pod 'GRDB.swift', :branch => 'Xcode8.3beta'

Pour SQLite:

Note: SQLite.swift requires Swift 3 (and Xcode 8) or greater. If you absolutely need compatibility with Swift 2.3 you can use the swift-2.3 branch or older released versions. New development will happen exclusively on the master/Swift 3 branch.

Là , ça devrait marcher tout seul.

toolsDev · janvier 2017

Merci Larme je refais un projet et reviens vite....

le soucis étant bien souvent situé entre la chaise et l'écran... J'aurais dû faire attention à la branche avant de crier "ça marche pas"

groue · janvier 2017

Pour ce qui est de Xcode 8.3 beta (qui est sortie, quoi, hier ? avant-hier ?) - je me suis juste assuré que les tests fonctionnaient. L'intégration CocoaPods ou autre n'est pas du tout vérifiée. On est dans le monde bêta, on est bien d'accord : il ne faut pas s'attendre à ce que tout marche du premier coup. Toute aide est bienvenue.

groue · janvier 2017

Cependant, pour Xcode "normal" (non bêta) en Swift 3, GRDB est très sérieusement blindée : il faut utiliser la dernière version: v0.101.1.

toolsDev · janvier 2017

je n'avais pas remarqué qu'une mise à jour de Xcode avait été lancé, je bute sur les dépendances de cocoapods.

visiblement les versions auraient changé, le terminal n'est pas content ..

pod 'AFNetworking', '~> 2.6'

pod 'ORStackView', '~> 3.0'

pod 'SwiftyJSON', '~> 2.3'

je cherche les nouvelles version là , mais je suis surpris que cocoapods n'a pas une commande de mise à jour ( comme composer)

bref, je vous explique ma procédure :

cd/monProjet

monProjet pod init

je rajoute les dépendances dans le podfile fraichement créer



# Uncomment the next line to define a global platform for your project

# platform :ios, '9.0'



target 'jeux_video' do

# Comment the next line if you're not using Swift and don't want to use dynamic frameworks

use_frameworks!



pod 'GRDB.swift',

pod 'AFNetworking', '~> 2.6'

pod 'ORStackView', '~> 3.0'

pod 'SwiftyJSON', '~> 2.3'

end



# Pods for jeux_video



target 'jeux_videoTests' do

inherit! :search_paths

# Pods for testing

end



target 'jeux_videoUITests' do

inherit! :search_paths

# Pods for testing

end

ainsi comme vous le voyez je rajoute le pod GRDB.swift

puis pod install

et là erreur (il ne doit pas trouvé les bonne versions)

pourtant je tente un pod update mais cela ne fonctionne pas.



[!] Invalid `Podfile` file: syntax error, unexpected tSTRING_BEG, expecting keyword_do or '{' or '('

pod 'AFNetworking', '~> 2.6'

^

/Users/Desktop/jeux_video/Podfile:9: syntax error, unexpected ',', expecting keyword_end

pod 'AFNetworking', '~> 2.6'

^.



#  from /Users/Desktop/jeux_video/Podfile:9

#

#    pod 'GRDB.swift',

>    pod 'AFNetworking', '~> 2.6'

#    pod 'ORStackView', '~> 3.0'

#

Larme · janvier 2017

J'aurais tendance à dire :

pod 'GRDB.swift', => pod 'GRDB.swift' (sans la virgule).

groue · janvier 2017

"syntax error" c'est assez clair : tu as laissé une virgule à la fin de la ligne GRDB, et ce n'est plus du Ruby valide.

Si tu as du temps pour mettre à jour les autres pods, tu peux aussi te pencher sur :

- remplacer AFNetworking par Alamofire (c'est la version Swift).

- utiliser UIStackView (disponible dans UIKit depuis iOS9) à la place de ORStackView

toolsDev · janvier 2017

je pensais que cela fonctionnais comme du json ...

J'imagine que Alamofire est donc plus conseillé ?

je regarde tout ça de suite merci à vous 2 !

Edit:

ça fonctionne bien, la virgule était bien le soucis

Edit 2

Projet créer avec la branche beta 8.3beta

et j'ai 151 erreurs trouvé dans la classe SwiftyJSONE et ça, direct, sans avoir rien modifié.

Edit 3

bon, c'est quand même pas clair dans la documentation, mais je doit visiblement lancé le projet depuis le jeux_video.xcodeproj

et non depuis le App.xcworkspace, comme indiquer dans la Doc :

``

Make sure to always open the Xcode workspace instead of the project file when building your project:

$ open App.xcworkspace

Céroce · janvier 2017

La doc est exacte, avec Cocoapods, il faut toujours ouvrir le workspace. Autrement, le projet de l'appli n'a pas accès aux pods.

groue · janvier 2017

Tu te donnes des difficultés avec Xcode 8.3 beta (sorti avant-hier) : rien ne dit que toutes les bibliothèques que tu utilises sont mises à jour.

Pourquoi n'utilises-tu pas Xcode 8.2.1, afin d'être assis sur une branche stable ?

toolsDev · janvier 2017

Depuis le début vous me parlez de cette mise à jour, pensant que s'était fait automatiquement ,mais je viens de vérifier à l'instant et je suis bien sous Xcode 8.2.1

bon, de toute façon je vais tout supprimer (il n'y a rien de fait dessus donc pas très grave) et tout reprendre.

voilà la raison pour laquelle j'avais fuit GRDB.swift pour SQLite.swift mais au final aucun des deux fonctionne pour moi... Une simple connexion et un SELECT sur une base de données sous JAVA m'aurais pris... deux minutes !

Alors que là , j'en suis déjà à 2 jours incroyables...

Et je peux pas me considérer comme nul ou pas à l'écoute de mes recherches.

La doc est exacte, avec Cocoapods, il faut toujours ouvrir le workspace. Autrement, le projet de l'appli n'a pas accès aux pods.

Pourquoi j'ai toutes ces erreurs du coup ... ? Mystères (le pire c'est qu'il me réclame l'import SQLite et non je ne me suis pas trompé dans le build cocoapods, j'ai bien choisi le bon pod...

groue · janvier 2017

Super. Alors pense bien à utiliser les versions "standard" des libs, comme indiqué dans leur documentation. Pour GRDB, ça signifie pas de branche, puisque la doc spécifie bien que la branche Xcode8.3beta est pour... Xcode 8.3 beta (et donc pas pour Xcode 8.2.1).

Et tout devrait aller comme sur des roulettes.

toolsDev · janvier 2017

oui exacte !

à force de faire et défaire mes projets, tu as raison j'avais zappé que je viens de build un projet cocoapods pour la branche de dev...

j'y retourne ::)

Edit:

bon j'ai re build un projet là plus d'erreurs.... on ce calme -_- je reprends tout au propre...

cette fois je re tente une connexion et un SELECT via la doc de GRDB.swift et vous redis ça.

Edit 2:

ça été vite...

une fois le projet build une 1er fois, j'ai ce warning :

/jeux_video/jeux_video.xcodeproj Update to recommended settings

connexion base de données SQLite direct ou via ORM (swift3)[réglé]

Réponses