Importers (requests & poll)

[Jerry]

Update

1.7 done.

IPB threads parent id's changed. ubb posts parsning, corse functions for vB3 importer.

OT in testing ,vB3 importer about 50% done.

[mfowler70]

I was able to successfully import my PNphpbb2 database tables into vbulletin. Any of you guys in need, just send me a PM.

Mike

[vb-hispano]

vb3 is first you'd must do, because is a help to vbulletin comunity

[poolking]

vb3 is first you'd must do, because is a help to vbulletin comunity

Have you read Jerry's latest post?

[Razgo]

go yabbse!! can't wait. it's so close i think i can taste it

[vb-hispano]

Have you read Jerry's latest post?

nop, sorry jerry

[Jerry]

nop, sorry jerry

No problemo I'm working on it at the moment.

[Jerry]

go yabbse!! can't wait. it's so close i think i can taste it

Just started it

[Razgo]

ok i just put my bib on to catch the drool in anticipation

[Steward]

My suggestion: Do it in halves

Define a text layout which can survive over time and versions. A windows INI file is an example. Something with NAME=VALUE pairs, organized into sections and/or categories etc.

Always import into vb from this. The importer takes care of missing values. You cannot know what the other fellow is supplying. Stop trying.

Now all other importers are a matter of dumping into that format.

You could even document it, and let other people convert their own data into that format, then use your script to suck it into vb.

It appears to me you have done something sexy with the importers. Objects and classes and not a helluva lot of documentation. You are dealing with people who are new to the software, and are looking to get this one step over with so they can get their hands dirty. I speak for myself of course.

Keep it simple.

Good luck.

[Jerry]

Well I looked at lots of different ways of doing it and the system that I came up with in the end does 3 things, firstly keeps the data model of vB intact by only allowing valid data to be imported, the vB2 importers would often break the database and loose dependencies.

Secondly it hides a lot of the workings in the core system to abstract the separate importers away from it, so there is no dependency on the source.

Thirdly is makes writing the imports easy (ok, I'm bias as I wrote it, but its true) because mostly all you have to worry about is the middle part of any module where you add the mandatory and non mandatory data.

I did think of value paired system where you would define matches in something like an INI file, but there is too many holes in the design and it doesn't cater to lots of different data sources. You'd have to get the source data some how as well.

As it is the vast majority of the time you do know what the other person is supplying, but more importantly you know what you can accept, ImpExData takes care of all that with is_valid() so you don't have to worry about it.

I did do (and released) a OO-API doc with ImpEx, there are more tools that go with it, most of the code for the system is automatically generated as it is.

Compared to vB3 its fairly simple, its just the design lent itself to OO better than structured.

As for other people developing with it I am working on some docs and other resources to make this easier.

Cheers for the feedback

[Steward]

Your model is fine

I understood the beauty of your model immediately.

It does not make writing imports easy for a stranger. I do not want to know the details of vb, and I appreciate your hiding them.

But you hid the baby with the bath water, so to speak.

Although you have hidden the ugly details of vb from me, you have also hidden the stunningly seek and perfect details of your importer module. I am lost in pages and pages of techincal documentation and scripts.

I did think of value paired system where you would define matches in something like an INI file, but there is too many holes in the design and it doesn't cater to lots of different data sources. You'd have to get the source data some how as well.

Yet, in another thread somewhere (http://www.vbulletin.com/forum/showt...122#post671122), you have asked me for a sample user file.


A simple example would help me wonders...

1. Make sure your script is in this place and has these headers.
2. Create this object or that object.
3. Feed this object your database details.
4. Modify this function to handle field conversions.
5. Run your script and poof, your member file is converted.

So I guess my suggestion is: documentation for idiots with a simple task at hand.

Lord knows I can be an idiot.

Cheers

[jacobi]

Discus/Discus Pro

Hi Jerry -- Now I'm really confused. Judging by this post, the converter that's listed as "done," i.e., "DC Forum+ / Discus Pro" is actually only DC Forum and not Discus. You apparently misinterpreted my request of several weeks ago to add Discus to the poll (though you referred to flat file or MySQL backend -- both of which could mean Discus), and now I erroneously rallied, and misdirected other Discus users to vote for DC Forum, pushing it up to "finished" status very quickly. As I alluded to in this thread, I have been going back and forth with vBulletin staff for quite some time now. Now, I fear that even if you do add Discus to the poll, it will be a start from ground-zero, and all of us who voted for DC Forum or "other" will have no recourse.

Please help. Please.

[ducasi]

I hope vB2 gets done soon - it's not at the top of the vote list, but it surely must be easier than, say, Yahoo groups?

I've got a fairly large forum that I want to move over to vB3, but it has been tweaked quite a bit and I need to figure out how to tweak vB3 in the same way.

I don't want to have to do all my modifications twice and I have to keep downtime to the absolute minimum, so being able to perfect my vB3 install while the vB2 one continues and then once I'm ready doing an import, would be fantastic.

Cheers!

[Jerry]

Yup anything with a database back end will be easier, and faster to develop.

The poll is just one factor that effects the order they are done in, probably the strongest deciding factor though