grr - just realized something

[jae77]

grr - i just realized something that is kind of annoying....

since nukes is a port of postnuke, that means unless we want to write migration scripts, we're stuck w/ their database schemas so ppl are free to easily move to nukes w/o any data loss.

that bothers me for a couple reasons...

1) their column naming conventions can be a bit confusing (i'd rather see things like "topic id" spelled out instead of "tid".

2) it will prevent some schema modifications.

something to think about if you hadn't before. was the downloads module schema done from scratch (i assume it has one, pls pardon my ignorance) or was it based on the post nuke schema?

[jae77]

on another note - does anyone have any documentation that details what their database schema means?

i keep getting errors trying to access it on their site.

[sgwood]

I think this is a philosophical discussion.

Are we trying to provide a drop-in replacement for PHPNukes - replace the code and not the database?

Or are we taking PHPNukes as an example of a successful project and community, and building the same thing in JBoss Nukes?

I believe it is the latter.

So take PHPNukes as an example which has some aspects that work really well for people, like the BB module, but don't be hamstrung by always trying to directly recreate PHPNukes functions, look and feel, database structures etc. If we can do that and blend in the JSR 168 capabilities, we will have a killer app.

My 2c,


Sherman

[starksm64]

Correct, the legacy of PHPNukes is irrelevant. Migration of databases is not required or desirable. Make the schema what it needs to be.

[julien1]

yes that is the idea I want ot share !!!

today Nukes has evoluted from the original Postnuke. At the very beginning it was a carbon copy and since then it has drifted in our direction.

Bottom line : we must retain from Postnuke the ease of use and the killer modules : news, forums.

We can adapt other module from other applications coming from the phpworld.

[thepriz]

I didn't like the Post Nuke database naming conventions. When I did the downloads module I did the module from the ground up using my own naming convetions ( which was using downloadId instead of pn_id or somthing like that.) I am also redoing the polls database and renaming all the fields like this. I am redoing it a little so polls can also be displayed in a list on the main page instead of just in a block. I like Juliens point that we need to not stick with the Post Nuke arcitecture and base are arcitecture off the power of the jboss server.

[jae77]

i'm w/ you - i'm not a fan of the non-descriptive column names either. too confusing to try and figure out what they mean.

the benefit of not being tied to any post nuke implementation (database or otherwise) will provide lots more flexibility.