News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

Saving the good stuff

Started by fearless, May 21, 2012, 04:11:53 AM

Previous topic - Next topic

fearless

As the old forum will be available for a while, and i take it there is no easy way to import all of the old posts from the old board (perhaps thats a good thing), i assume there is some stuff where reposting here would be handy. I myself search the forums (old one) and find it always to be a wealth of information. So im afraid to lose that resource (but i understand the why of it), hopefully some of the main users will have time to 'port' over their most useful posts. As to which ones are more valuable than others, i cant say, and im guessing each author will have the same dilemma.

Anyhows, onwards and forwards and upwards and all that jazz.

BytePtr

Just posted a question in romper room about old forum and posts.
Very sad. All these topics, including OpenGL section, 16bit section etc etc, lots of good info will be gone. Seems to be really true  :icon13:
I don't think that everybody will re-post everything.

hutch--

It will stay up for as long as I can leave it there but it is no longer maintainable. The last database was 665 meg and I did not have enough disk space to gzip it so I had to download the MySqlDump in its raw form to ensure I had all of it. Then there was 180 meg of attachments which I also downloaded but they did not take all that much work to rename so they could be posted as an archive.

I stuffed as much of it as I could load into the server database but syntax changes to the format over 8 years have made it incompatible with current MySql notation so its not fully functional on a 64 bit server. The old forum software will not even install on it, I manually loaded all of the files but cannot get the database going to run it. There were also PHP errors which did not help.

BytePtr

Hutch. You said that you got a MySqlDump. So this means all the forum topics and posts are at you and saved in safe place (even if you can't use the dump), including all attachements? Correct?

Im just worrying here about all that good info, the old forum had.

dedndave

it would be nice if you could write a little program to save the name of the attachment files into the thread post message text

it is sometimes difficult to locate the archived attachment that goes with a specific post

we know you are busy at the moment...
...so, we'll give you some time - lol

hutch--

Yes I have the lot, 660 meg of raw database that I cannot even edit at the moment and 180 meg of raw encrypted name attachments. I have them done and archived as downloads but the database will be no joy to get any data from. the PhpMyAdmin cannot even load it, its 600 meg too large for it, it has to be done with vintage MySql comands.

Still there is no point griping about it, the old forum will be there for many months yet.

Tedd

So, I was considering making a local mirror of the old forum, with a view to then processing it and making some kind of compacted, searchable, database/mini-site/documents (not sure yet, suggestions welcome.)
That's still doable, but obviously downloading all pages would take a while, and longer if I throttle to avoid killing the server.
Alternatively, if I could take the raw database, then I can try converting it into something usable (SQLite?), and then decide how to process it and produce something useful.

Thoughts?
Potato2

hutch--

tedd, the raw database is about 660 meg.

jj2007

Quote from: hutch-- on May 22, 2012, 03:23:43 AM
tedd, the raw database is about 660 meg.

That's quite a lot, of course. The question is how it could be processed. Is it split over a thousand files, or a monolith? How does the format look like, is it a human-readable text or binary? Searching could be slow, I wouldn't mind even a captcha to discourage too much playing etc...

dedndave


Antariy

Quote from: jj2007 on May 22, 2012, 03:36:34 AM
Quote from: hutch-- on May 22, 2012, 03:23:43 AM
tedd, the raw database is about 660 meg.

That's quite a lot, of course. The question is how it could be processed. Is it split over a thousand files, or a monolith? How does the format look like, is it a human-readable text or binary? Searching could be slow, I wouldn't mind even a captcha to discourage too much playing etc...

We need a hardcore PHP+MySQL programmer, who will write relatively small PHP proggie which will export all the messages from the old forum, and save it in sorted order for the each thread into simple text file with selected format. Then other PHP proggie on this forum will import this text file - parse it and recreate a "mirror" of the old database.

Volunteers? :biggrin:

hutch--

You are in for even more fun, the old forum software will not run on later versions of MySql and PHP so I am currently playing with various versions of WAMP on my local machine to try and get a combination where it will run. Apache always works well, the older pre Oracle versions of MySql used to work OK and setting up PHP has always been a pig to get going, later versions are just as badly behaved and poorly documented.

I tried installing the old forum software on the new server but it generated errors in both MySql and PHP.

On my local box the new forum software runs fine in a WAMP server.

JJ, the database dump is one big ASCII text file in Unix format LF with no CR before it.

Antariy

But if run the exporting PHP proggie on the old forum - it will run on the old version of PHP and will access the old database via old vesion of the MySQL runtime, and it will work fine :biggrin:

If the database dump is available in the text format already, then there anyway is need in programmer who will write PHP proggie to be run on the new server to import this data properly into the new database.

Why the MySQL vendors don't care about compatibility? Why they do not provide the tools for conversion old database format into the new one? Maybe they implied that this will be done via export-import way (the way I've suggested here, though I'm not a PHP coder :biggrin:, and cannot do this (obviously not very hard) task).