[spip-dev] SPIP multi bases ...

Dev
1

Bonjour,

histoire d'accélérer les réflexions hésitantes menées sur
l'utilisation de SPIP avec d'autres bases de données que MySQL depuis
6 mois, tout en évitant de saturer spip-dev avec ces discussions, je
viens de créer un groupe Yahoo! dédié :
http://groups.yahoo.com/group/spip_multi_bases/

L'inscription est libre, et les archives de messages sont accessibles
librement.

Le but est de déterminer comment faire évoluer SPIP pour qu'il puisse
fonctionner avec d'autres bases de données que MySQL, les deux cibles
principales dont nous avons discuté au cours des derniers mois étant
PostgreSQL et Oracle.

La piste principale pour l'instant est d'ajouter une couche d'accès
aux données, qu'elle soit ou non objet. Une idée serait par exemple
d'avoir des fonctions getArticle(), putArticle(), updateArticle(), et
autres, pour tous les types de données ...

SPIP devant (?) conserver la compatibilité avec PHP3, l'usage d'objet
n'est pas forcément souhaitable.

-Nicolas

2

Salut,

histoire d'accélérer les réflexions hésitantes menées sur
l'utilisation de SPIP avec d'autres bases de données que MySQL depuis
6 mois, tout en évitant de saturer spip-dev avec ces discussions, je
viens de créer un groupe Yahoo! dédié :
http://groups.yahoo.com/group/spip_multi_bases/

L'inscription est libre, et les archives de messages sont accessibles
librement.

Good idea, mais pourquoi un groupe en anglais ;-))
le même sur fr.groups.yahho.com eut été plus agréable, non ??
Bon d'accord, je chipote mais quand même ;-D

Le but est de déterminer comment faire évoluer SPIP pour qu'il puisse
fonctionner avec d'autres bases de données que MySQL, les deux cibles
principales dont nous avons discuté au cours des derniers mois étant
PostgreSQL et Oracle.

La piste principale pour l'instant est d'ajouter une couche d'accès
aux données, qu'elle soit ou non objet. Une idée serait par exemple
d'avoir des fonctions getArticle(), putArticle(), updateArticle(), et
autres, pour tous les types de données ...

Tant qu'à faire, pourquoi limiter la réflexion au seul domaine des bases de données.
On pourrait réfléchir, compte tenu des utilisations de SPIP qui sont dans certains cas très orientées pro, à une espèce de "Load
balancing compatibility", sur laquelle je travaille à l'heure actuelle, ou autre sans limitation.
Bon, je sais, c'est pas forcément le but de SPIP et le besoin sera peut-être restreint, mais après tout pourquoi pas ??

SPIP devant (?) conserver la compatibilité avec PHP3, l'usage d'objet
n'est pas forcément souhaitable.

La dead line de php3 est toujours fixée à l'été prochain, non ??
Parce qu'à ce moment là, on pourrait imaginer une version 2.0 de SPIP qui effectue la rupture.
Enfin, il faudrait surtout savoir quelle est encore l'utilisation de PHP3 par rapport à la 4.

En tout cas, je m'inscris de ce pas ;-))
@+
JB

3

> histoire d'accélérer les réflexions hésitantes menées sur
> l'utilisation de SPIP avec d'autres bases de données que MySQL depuis
> 6 mois, tout en évitant de saturer spip-dev avec ces discussions, je
> viens de créer un groupe Yahoo! dédié :
> http://groups.yahoo.com/group/spip_multi_bases/

Histoire de ne pas perdre les infos sur ce travail, et conserver la
cohérence des archives, il est finalement choisi de rester sur
spip-dev.

spip_multi_bases n'existe plus ... mais je vais forwarder ici les deux
messages qui y sont passés aujourd'hui ... :wink:

Voici donc l'un des groupes de discussion les plus éphémères qu'il m'ai été donnée de voir ;-D
M'enfin, l'idée de regrouper les archives est bonne.

Ceci étant, je trouve que l'idée d'un "groupe de travail" dédié à l'implémentation d'un spip multi-base l'était tout autant.
Cela aurait évité de "polluer" les boîtes au lettres de ceux qui ne se sentent pas concernés par cette affaire.
On aurait pu alors livrer nos conclusions à spip-dev pour en débattre les idées claires.

Mais, encore une fois, ceci n'a d'autre but que de faire avancer le schimlblick, pas de démarrer une polémique sans réel intérêt.

Je suis toujours intéressé par le sujet, même si ce n'est pas ma spécialité ;-))
@+
JB