The Arcive of Official vBulletin Modifications Site.It is not a VB3 engine, just a parsed copy! |
|
|
#2
06-25-2005, 08:50 PM
|
|||
|
|||
vB3.0 don't support other database types then MySQL. In vB3.5 Beta there are some still limited methods build in that could possibly be used to support more database types. At this moment however there is no support for this.
|
|
#3
06-26-2005, 05:08 PM
|
|||
|
|||
|
Quote:
|
|
#4
06-26-2005, 09:47 PM
|
|||
|
|||
|
That would be a huge hack. A lot of MySQL specific SQL-commands are used.
|
|
#5
12-09-2005, 08:30 PM
|
|||
|
|||
|
A HUGE hack indeed
 BUT .... I've just about completed it. I'm in the final bug testing stages right now in fact. I also wrote a quick and dirty app to migrate existing forum data from MySQL to an existing PostgreSQL database (created by my ported vB installer). Once I have a few million posts loaded into it, I'll be doing some stress testing and performance measurements, which will then undoubtedly lead to some work on index optimization and what not. With three forums, about a half dozen "users" online at once, and 600 posts, it absolutely flies though  I'd like to see at least 1500 to 2000 concurrent users online, with 4+ million posts, all features active, utilizing two servers (1db + 1httpd).I've done my best to stay close to SQL92 throughout, but there's some PG-specific syntax and functionality I left in there in the interest of time. A few other things, instead of completely re-writing sections of code, I simply made stored procedures for. A *LOT* of areas I cleaned up the existing vBulletin code for more efficiency. As I have plans to use this in a production environment, I also coded everything with the intention of it being maintainable, so I can stitch in updates from Jelsoft as they come in. I converted vB 3.5.0 so the real test will be my upgrade to the latest version (3.5.2 at the time of this posting). I originally had the thoughts of testing against a couple of the "big name" DB engines (IBM DB2 UDB 8.2, Oracle 10g, and Sybase ASE 12.5.2 specifically). Now that I've done all this work with Postgres, I think I'll just cut the strings for now and finish up. lol. Its simply astounding how much effort this has taken to completely port vBulletin over. I started back in early November, and am just now finishing up with the last dozen or so bugs. Definitely not an easy "hack," and to support it will take someone very fluent and comfortable with PHP, and both MySQL / PostgreSQL. At some point, I'm sure Jelsoft will keep moving towards a package that will natively support multiple database backends as well. The first iteration, I'll be testing with the built-in search engine, we'll see how that works out. I'm going to be installing the Tsearch2 module into PostgreSQL, and switch over to fulltext searching and try that out as well. I'm definitely curious to see which method excels in which areas. I'm also going to set up multiple machines, and bring up a PostgreSQL replication set ("cluster", if you will). That should mesh very easily with vB's built-in master/slave server code.
|
|
#7
12-10-2005, 01:35 AM
|
|||
|
|||
|
Do you have a running, functioning system on a DB backend other than MySQL? I'd be very interested to learn of your success and/or failures, and in which areas. I'm just getting to the testing portion (migrating data as we speak, in fact).
Updates won't be straight-forward, for sure. Thus far I haven't gone through one at all -- I simply ran the (converted) vBulletin installer, which generated a clean new system with a PostgreSQL backend. I then wrote a very simple app that does nothing more than truncate the PG tables, and then select data from MySQL tables and insert it into the PostgreSQL tables. My plan is to grab each set of changed PHP files and simply do a DIFF against the original Jelsoft-delivered code. Once I have a clear idea of what changed, manually patching in the changes should be relatively straight forward. The PHP upgrade scripts in the /install folder will need to be tweaked for each update though, so the database changes are applied properly. Those should not be too tough.
|
|
#8
12-10-2005, 11:55 PM
|
|||
|
|||
|
I had a working vb2 with the database abstraction layer DB (from Pear). I would work on it again, but updates are such a hassle. Don't really have the time to diff each file and migrate changes.
Lately I thought about doing "something" inside vbquery(). But that would involve parsing the query itself. So one could get around MySQL specific functions and SQL.
|
|
#9
12-11-2005, 12:35 AM
|
|||
|
|||
|
Ahh, I see... I took a much more "traditional" porting approach, and changed all the code over to more SQL92-style queries throughout, and then wrote a new class-core.php that supports PostgreSQL. With further tweaking, the application would be able to directly support both MySQL or PostgreSQL with just a change in config.php (instantiating the proper class in class-core.php). Doubtful that I'll finish that up, because PG is doing what I want it to, but the possibility is there.
|
|
#10
12-12-2005, 01:12 PM
|
|||
|
|||
|
Quote:
Which is why I thought about creating a sophisticated parser which is run inside vbquery().
|
 |
«
Previous Thread
|
Next Thread
»
Linear Mode
|
|
All times are GMT. The time now is 03:26 PM.