130 min
c’est le temps qu’il faut à juniter, pour verifier tout les blocs 1 par 1, c’est beaucoup mais c’est presque un ordre de grandeur en moins par rapport à la version 1.6 SQLite qui m’as servit de réference.
il y a encore de nombreuses amélioration possible, des vérifications à faire mais disons qu’après plusieurs réecriture, je penses que c’est pas si mal étant donnée que vous pouvez le brancher (via une simple conf) sur votre SGBD favoris grâce à JPA (couche sql agnostique). pour une liste exhaustive des bases compatible c’est ici
Si vous développez des outils et souhaitez directement accéder à votre blockchain dans les règles de l’art SQL, c’est donc à nouveau possible.
Je remercie au passage @kimamilla dont l’un des (petit mais non négligeable) conseil m’a permis de diviser par 3 le temps de synchro.
Pour ceux qui n’ont rien compris, en gros ya des tables et ca ressemble à ça :
Quelques point:
- Juniter ne supprime pas ses vieux indexs … le ménage c’est pas mon truc, mais pour la forme, il vaux mieux dire que c’est pour avoir l’historique sous la main.
- Juniter dénormalise des champs, entrainant un peu de redondance mais un requétage plus rapide, ainsi que pour élargir le nombres de champs requêtable (numéro de block/date)
- Juniter à sa propre interface pour filtrer, trier, requêter, visualiser la base.
- Juniter peux synchroniser block par block, jusqu’au block X ou bien jusqu’à la fin !
- Juniter peux revert tout l’index, ou, block par block (parce que c’est la classe de piloter les forks en manuel ! )
- Juniter à une clef publique si vous aimez et souhaitez financer sont developpement:
77UVGVmbBLyh5gM51X8tbMtQSvnMwps2toB67qHn32aC
Juniterrement vôtre