De l'utilisation de SQLite

chaps31chaps31 Membre
08:47 modifié dans API AppKit #1
Bonjour à  tous,

Voilà  que je vais me remettre à  coder, quelle idée  ;D  Tant d'heure à  m'arracher les cheveux à  venir mais  ::) . Ma question du jour vient d'une découverte sur le net : SQLite n'est pas monoposte ! J'ai toujours cru l'inverse. En fait plusieurs postes peuvent accéder à  une base SQLite mais lors d'écriture la base est bloquée donc les autres sont en attente. En pratique on parle de millisecondes, donc mon projet étant pour entre 1 et 5 postes en réseau local je me dis que vraiment pas de soucis, oublié les relation client-serveur !

Revenant dans la programmation je me demandais aujourd'hui qu'utiliser pour pouvoir intégrer une base SQLite à  un projet cocoa ? Il me semble que Core Data n'est au final pas la meilleure solution, donc avez-vous des pistes ?

Merci.

Réponses

  • muqaddarmuqaddar Administrateur
    08:47 modifié #2
    CoreData est certainement la meilleure solution mais elle demande un temps d'apprentissage certain.

    Si tu veux utiliser SQLite, je te conseille le Framework suivant:
    https://github.com/ccgus/fmdb

    Je l'utilise beaucoup et il est très simple.
  • chaps31chaps31 Membre
    08:47 modifié #3
    Merci de ta réponse, je vais de ce pas regarder ton lien. TU as l'expérience d'éventuels "attentes" avec SQLite si plusieurs accès sont simultanés ?
  • muqaddarmuqaddar Administrateur
    08:47 modifié #4
    En fait, je ne comprends pas ton problème.

    Tu veux l'utiliser sur un serveur ou bien dans ton app ?
    Mon lien est pour le mettre en local dans ton app.

    Je l'ai toujours utilisé avec une seule app donc je n'ai pas de retour sur les multi-accès, ni comment ça marche.
  • chaps31chaps31 Membre
    08:47 modifié #5
    Arghh.... "bad request" sur mon pécédent post... En résumé non, monoposte pour l'instant masi sans doute multiposte plus tard en réseau local de 5 ordi max.
  • zoczoc Membre
    novembre 2011 modifié #6
    Oui mais non... En pratique SQLite est bien monoposte, mais plusieurs process sur le poste peuvent attaquer la même base simultanément: La documentation de SQLite déconseille fortement de mettre les bases de données sur un système de fichiers partagé (genre NFS, AFP ou SAMBA"), à  moins de développer soi-même un système interdisant les écritures simultanées:

    "You are advised to avoid using SQLite on a network filesystem in the first place, since performance will be slow. But if you must use a network filesystem to store SQLite database files, consider using a secondary locking mechanism to prevent simultaneous writes to the same database even if the native filesystem locking mechanism malfunctions."

    Maintenant, techniquement, même sur un même poste, c'est très chiant, il faut gérer plein de cas d'erreurs supplémentaires (timeout sur les lecture/écritures) qui n'arrivent jamais quand la base est utilisée par un process exclusif. Je me suis arraché les cheveux dessus (avec derrière moi un boss qui voulait que ce soit fait "pour hier").
  • chaps31chaps31 Membre
    08:47 modifié #7
    Arghh.... Et moi qui avait lu que SQLite empêchait les écritures simultanées, le seul problème relevé était en cas de nombreuses requêtes ça va se mettre à  ramer... Bon, va falloir que j'y pense sérieusement alors, moi qui voulait éviter PostgreSQL... Je ne vais pas avoir le choix il va falloir que je passe par un serveur...

    C'est fou ça pour gérer en local sur 5 postes une BDD pas le choix... serveur/client...
  • zoczoc Membre
    08:47 modifié #8
    Accessoirement, SQLite n'est même pas thread-safe: Il ne faut pas partager des connections de base SQLite entre plusieurs threads, mais plusieurs thread peuvent ouvrir la même base.


    C'est d'ailleurs pour combler cette lacune que le développeur de fmdb a une branche dédiée sur son github où il utilise un pool de connections, exactement ce que j'avais fait à  l'époque (mais c'était en C++ sous Windows & Linux).

  • chaps31chaps31 Membre
    08:47 modifié #9
    Et avec fmdb ? C'est jouable ?
  • zoczoc Membre
    08:47 modifié #10
    Non, clairement pas, fmdb ne règle pas le problème du locking non sûr des systèmes de fichier réseau.

Connectez-vous ou Inscrivez-vous pour répondre.