Custom backend with different table layout?

[Migrated From Jforum.net]

Hi,

Can I exchange JForum's backend against a custom backend that I design myself? How hard would it be (e.g. developer months)?

This might seem utterly crazy, I realize, but the situation is this that the company where I work has already developed a server, a client (which is somewhat similar to a Web browser, but does very different things (it runs [code stored in our database] on an user's computer)), and uses a data base with our own custom table layout and our own manner of storing users and data values etcetra. For the forum to be available in our client application, we need to store the forum data in our regular database tables, so our server can retrieve data and deliver to the client. We would store at least forum user data and thread messages and [forum and sub-forum hierarchy information] in these tables.

We also want a Web version of our forum -- hence my interest in JForum, and in modifying the JForum source code.

I know nothing about the internals of JForum, but my wild guess is that we would attempt to exchange [all JForum classes that write to database] with our own classes, which instead store data in our own tables.

( Some details:
1. Our database tables store data in a virtual folder hierarchy: There is a table that looks something like FOLDERS( folder_id NUMBER, child_folder_id NUMBER ).
2. We store files, text, binary data and images in these folders. The data value table looks something like: DATA( data_id NUMBER, data_value BLOB, folder_id, ...)
3. We also have a USERS table.
Of course we could modify the database structure if needed, e.g. add some random columns to the USERS table :-)
)

(Again, I hope this is not too crazy.)

Kind regards,
Magnus
[originally posted on jforum.net by LeoMaheo]

[Migrated From Jforum.net]

Well, JForum 2.x uses a fairly well defined set of Data Access Object Interfaces (DAO) to access it's information. So, from the point of view of adding in your own DAO implementations, that's fairly straight forward.

I suspect that the big challenge is that all of these are based on the underlying DB being a fairly standard Relational (e.g. SQL) database. So, how easy it would be to convert to your proprietary system depends on how much Relational syntax it supports... like foreign keys and the like.

One thing to consider is that AFAIK jForum 3.0 will be dropping the DAO structures in favor of a Hibernate data access implementation. This means that there may be some major rework required if you want to upgrade to 3.0.

Also, I'm not sure how the new Lucene search code will play with a proprietary DB.. but I haven't dug in to that new code yet. Just something to look at.
[originally posted on jforum.net by monroe]

[Migrated From Jforum.net]

Hibernate. Hmm. And all this (that I wrote about) was supposed to be done with few resources, fairly quickly
:-)

I guess a more reasonable approach might be to keep the JForum backend unchanged, but in some way add [an interface to the Web server] that [delivers JForum database contents to our client] in a format the client understands.

Thanks,
Magnus

(By the way, concerning foreign keys and the like: we use Oracle.)

[originally posted on jforum.net by LeoMaheo]