news 1.1 alpha available

[jae77]

an alpha version of the news module has been checked into cvs. if anyone wants to check it out, please feel free. report all bugs in the bug tracker on sourceforge so it is easier to track them.

some of the changes you will see are:

- all tables are created upon deployment by default(w/ new table names). i've only tested this against hsqldb, but i haven't seen any problems. i'm hoping this will eliminate the need to maintain multiple ddl (setup.xml) files.

the setup.xml files haven't been updated, so if you choose to turn off table generation, you need to write the ddl (pls submit to sf if you do and i'll incorporate the work).

- the tables have been somewhat normalized and now link to the user table instead of storing duplicate information
- initial startings of administration page.
- all the links/forms should be working now.

i still have a few more columns to add to the db, so this is not the final schema as of yet. this means that the old schema is no longer valid, and if anyone was using the pervious versions, they will have to migrate any items they want to keep.

i have created a tag in cvs for the old news module: news-1_0. this should allow you to check out the new news module, yet revert back to code that will work w/ your existing tables.

also, i've only really tested the UI thus far w/ firefox - so i don't know how well IE is going to render all the screens.

edit:

in order to get the news menu options to show up for non-admin users, add the following to the menu-block-service.xml's security section.

<permission group="Users" level="COMMENT" pattern="module:news:(main|submit)"/>

i refactored down some of the long operation names.

[julien1]

cool jae, this a the major point of the upcoming 1.1 release.

[smoyer]

This excellent news, (pardon the pun) but I've been one of those waiting to get news on my site! I love the idea behind the table creation, and I'd like to suggest something that would make it easier (though I'm a PostgreSQL user, so someone familiar with all three databases needs to decide whether this is feasible). I had actually considered posting this on the development forum a couple days ago, but it seemed that the ddl mechanism was pretty entrenched.

If there was a table in the Nukes core that stored a list of information about deployed Nukes modules, a field could be added that holds a version number of the module's database structure. The module itself check this table each time it deployed as follows:

1) If the module doesn't detect a previous installation of itself, it creates the tables it needs for the current version of the module.

2) If the module detects that the database structure is the same version as the current version of the module, it does nothing.

3) If the module detects an older version of the database exists, then it executes the commands necessary to upgrade the old tables to those needed by the new version of the module.

This could be done quite easily using a series of methods which were referenced in a static ArrayList. Then just execute all the methods representing version numbers greater than the current one and update the version in the database table.

This could even be used for the Nukes core ... if the module doesn't exist, then create everything needed.

I would be glad to design and code the engine needed to allow this functionality ... Is anyone interested?

[code11]

it's a stirring news!

[hxp]

Jae --

Good progress !!

I'm really happy to see the shedding of the ddl/sql, and your move towards pure-CMP!

-- Howard

[triathlon98]

In reply to "smoyer" :

There should be no need for this functionality.

JBoss can automatically update the table definition on redeployment (using alter-table combined with create-table).

There are some limitations/caveats :

- no change of field type (it only increases field length)
- new fields are always empty (null or 0)

IF you take these in consideration, then everything else should be completely automatic.

Joachim

[julien1]

actually this can be stored in the MBean itself, just add that Attribute on ComponentSupport

[hxp]

"jae77" wrote:

- all tables are created upon deployment by default(w/ new table names). ... i'm hoping this will eliminate the need to maintain multiple ddl (setup.xml) files. ...the setup.xml files haven't been updated...

Go, Jae, go!

"jae77" wrote:

so if you choose to turn off table generation, you need to write the ddl (pls submit to sf if you do and i'll incorporate the work).

Boo, hisss! No reason to go backward!
(Just don't. Don't turn off table generation; don't write ddl; don't invite submissions of ddl; don't waste your time offering to incorporate ddl ;-))

"smoyer" wrote:
seemed that the ddl mechanism was pretty entrenched

Yeah, after pouring "Draino" on that entrenched legacy ddl blockage for the past several months, I can feel some movement recently... we're at the beginning of a good big shift away from ddl.

"triathlon98" wrote:
JBoss can automatically update the table definition on redeployment (using alter-table combined with create-table).

There are some limitations/caveats :

- no change of field type (it only increases field length)
- new fields are always empty (null or 0)

IF you take these in consideration, then everything else should be completely automatic.

I agree 100%, Joachim, within the scope of your comments --- alter-table can indeed do what smoyer was proposing. And your comments are 100% consistent with the pure-CMP way of doing things.

There will eventually be, however, schema changes where a single entity gets split into 2 or more, or 2 or more entities are merged into 1, or where inter-entity relationships are radically refactored. In these cases, alter-table has no hope. (I've read the alter-table impl code, and seen other limitations.)

So while create-table/alter-table is a vastly better way to go than sql/ddl/setup.xml, we will also need a migration strategy in the longer term that allows migration among radically divergent schemata.

But not right away; getting to the basics of pure-CMP comes first.

see my most recent comments about moving to pure-CMP:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=49034

(As part of the pure-CMP architecture that I've been advocating, I'm proposing a dump/load utility that will evolve into a sophisticated migration facility. The general case will involve mapping old schema to XMLSchema, exporting data to XML in that schema, mapping new schema to XMLSchema, mapping the XMLSchemas and transforming the data (potentially with custom transforms other than schema maps), then importing data from XML.)

So my reply to smoyer would be....

"smoyer" wrote:
I would be glad to design and code the engine needed to allow this functionality ... Is anyone interested?

Sure we're interested, Steve... same motivation as you already expressed, somewhat different design... modulo the comments I just made... after you get your LDAP piece going, how about giving a hand with the pure-CMP migration... we need all the help we can get :-)

--howard

Anyway, how did it get to be 5am again -- shouldnt I be sleeping by now ;-) ??

--

[jae77]

i've checked in what i hope should be the last set of updates to the entity beans for the database. i think i've got all the columns i want to persist coverred.

i haven't tried to updating the tables via the "alter-table", so i don't know how that is going to work. based on what i read below, i don't think it will b/c i set "not-null" constraints on the additional columns i added.

i've also updated the original post to include what needs to be added to the menu-block-service.xml if you want to have these links show up for non-admin users - however since this is only the alpha release, this probably isn't necessary for now - only the admin user has full access to everything.

i leave for vegas (yeah baby!) tomorrow night, and won't be back till sunday, so if anyone runs into problems, you're on your own unless someone else here can help.

[julien1]

Jae would it be possible to integrate the parser stack used in the forums in the news module ? That would be a great enhancement. What about that ?

[jae77]

what is the parser stack? it's not ringing any bells at the moment.

[jae77]

ok - a quick trip to the wiki (to see what the "simple" task were from the other thread) was all i needed.

i definately think this is possible and was already thinking about doing that. i would probably want to slate it for a 1.2 release though.

since news is such an important module, i think it's best to first release something w/ solid functionality and then start adding in the additional goodies.