Zend FR

SVN
tu installe un serveur SVN
tu crée un repository (entrepôt)
ton SVN sera accessible par des URL Http:// .....

dans ton php tu fait un objet métier article et dans celui-ci tu implémente une persistance qui utilise tes url SVN pour accéder au données. SVN te propose tout ce qu'il faut ajout d'article, suppression, ajoute de version historique verrou etc.

A+JYT

je ne suis pas hors sujet

je dit qu'un moyen simple de versionner ses articles c'est de mettre en place un serveur SVN
et de faire un objet métier Article qui lit et écrit le contenu de ses articles dans dans le serveur SVN

ainsi sans développer de gestion de version les article (donc le contenu) est versioné

il faut ouvrir sont esprit

une application Zend ce n'est pas obligatoirement une appli qui qui stocke ses donnée dans MySQL la persistance peut se faire sous bien des formes Ldap DB (quelle qu'elle soit) fichier text fichier XML objet php sérialisé dans des fichiers,
tous support toute technologie de stockage de l'information peu servir à assurer la persistance des données d'une application
cvs ou svn Aussi

la question qui se pose alors c'est quand on a choisit un support comment y accéder
et pour SVN c'est simple le serveur fournis des URL http pour y parvenir et Zend fourni des classes pour utiliser des url


donc son appli peut très bien socker le contenus de ses article sur un serveur SVN au même titre qu'il le ferait dans MySQL

la gestion de version est donc native

A+JYT

Merci @sekaijin pour ta réponse, c'est vrai que c'est une bonne idée mais je sais pas si je vais pouvoir le développer sur mon environnement

Merci @omega2 pour ta réponse, c'est un peu ce que je voulais faire, mais je ne savais pas trop comment le développer "CORRECTEMENT"

Je ne sais pas trop si c'est mieux de faire ça en base de données car si beaucoup de version = beaucoup de données = temps de réponse mysql de plus en plus lente ou si c'est mieux de faire ça avec un système de fichier avec des données sérialisées mais la encore beaucoup de version = beaucoup de fichiers = peu être maintiens de cette environnement difficile.

Donc je ne sais pas trop sur qu'elle méthode utilisé pour avoir un système de version de contenu bien développer,stable et évolutif.

Des idées ne serait pas de refus

Merci encore pour ce temps pris pour m'aider

J'ai mis en place une gestion d'historique dans mon ORM maison :
Prenons une table à historiser, par exemple des page d'un wiki, j'ai une table page_history.

quand je fais un $page->save(), ça incrémente un numéro de version et ça crée une nouvelle ligne dans la table page_history.

ensuite quand je fais un $page->publish(), ça flaggue la page comme "publiée".

Quand je fais un $page->delete(), ça passe un flag en "pending_delete". Ensuite lors d'un publish, le flag passe en "deleted".

La page qui s'affiche réellement est donc la page qui a le flag "publish".

$page->unpublish() se contente de supprimer le flag "publish"

schématiquement la table va avoir au moins les champs suivants :

- id : id de la page
- version_number : version de la page
- content : contenu de la page
- is_publish : publiée ou non
- delete_state : null ou pending_delete ou deleted

Le couple (id, version_number) est unique, par contre le "id" n'est pas unique.

A+, Philippe

J'ai fait ce choix pour des raisons de performances et de simplicité de l'approche.

En fait j'ai ajouté un système supplémentaire : quand je publie, ça génère des contenus dans une table de cache => pour afficher les contenus en lecture, je n'ai pas besoin de toucher à la table history (qui est très grosse) et je précalcule l'affichage. Ca fait un gros gain de perfs. (et bien sur sur un unpublish ou un delete, j'efface de ma table de cache...)

A+, Philippe

Si, mais bon, c'est une admin. Si ça met 3s à répondre, c'est pas un drame... Pour l'instant je n'ai jamais eu assez de données pour que ça pose un problème.

Si tu comptes avoir autant d'articles d'articles que wikipédia, effectivement ça risque de poser problème

A+, Philippe