This project has moved. For the latest updates, please go here.

Packing older Graffiti databases to fix errors

May 15, 2010 at 1:05 AM

I did a blog post about this tonight ( Graffiti CMS database growing out of control? ) because I continue to get tech support tickets and public twits about how VistaDB is the problem.

Do you guys have any suggestions how we might solve this?

If the system would run pack (EVER) it would be fine.  If it actually did any maintenance on things like the stats table it would be fine.

The old graffiti uses a very old 3.x version of VistaDB.  I am afraid that if I write a pack util with the current 3.x code it will break the older installs.

I am open to suggestions on how to resolve this.  I can't keep spending time and money on support for Graffiti, it is like death by a thousand cuts.

 

May 15, 2010 at 1:30 AM

Guys, lets put some weight on this, I'm sure we all know that 1.2 is still the CloSS system, but many of our fellows are still on the old version having difficulty migrating past it. It's important to remember that we weren't wronged by the guys at VistaDB, and it is highly admirable that Jason is throwing his support behind us.

What do we know?

  • The VistaDB provider in 1.2 does not run pack, so the databases get incredibly large, incredibly fast
  • When VistaDB fails in 1.2, due to size or memory constraints, Graffiti locks up the entire system-- poor handling.
  • There is no simple way to migrate the schema or data in the 1.2 vdb3 file other than the DataMover-- which also works poorly.
  • All in all, Graffiti 1.2 poorly implemented VistaDB, with no solid way of maintaining or repairing database issues.

What can we do?

  • Merge into this project, or start another project, designed to assist 1.2 users migrate to 1.3
  • Discuss how to effectively maintain the vdb3 provided with 1.2, and discuss best practice for sidestepping the DataMover.

Is this too much? I don't believe so. As Jason and I discussed earlier, it is more important to move past this as a community than to bear grudges and ill will.

May 15, 2010 at 4:59 PM

I have an old version of the 3.3 engine that I think is used in Graffiti 1.2.  I can use that to build a quick pack utility that people could run on their database, of course they have to know to do that before their site locks up on them.

I willing to provide the tools to anyone working on the project, and to help with the process in any way I can.  But I can't take all the support requests on at my company, we are just too small to that this type of burden for something we didn't do.  I am sure many of you are also in small companies and realize that the economy has not been kind to small business in general lately.  

I can provide you guys with an ability to use the engine directly, and to pack the database.  What else do you need?  Would you like a tool that just extracts everything in the database out to an XML file for migration to something else?

We are actually getting ready to release a new tool for database migration to and from several different vendors, but VDB3 is not currently in that supported list.

What would be the best way to provide such a tool?  A simple API access to SaveVdb3ToXML( path ) - something that is really easy like that could be done through an API quickly.  But I have no idea how to build the Graffiti pages to show this API to the users.

I wish it were as simple as upgrading the current code to use vdb4 (VistaDB 4).

 

May 15, 2010 at 10:42 PM

I have experience with VistaDB programming, but not with Graffiti, so if someone (or multiple someones) can give me an idea of what it is you need or want in relation to the VistaDB problems, I am willing to see what I can do to help out.  I would obviously need information regarding what the exact problem is, what you want/need done, and then I could see what I can do to help out.

EricB

Jun 2, 2010 at 5:23 PM

We just built a free tool for people to pack, repair, and export to XML their VDB3 database.

Free VDB3 Database Tool

Hopefully this will help those who are still running the old Graffiti CMS.