1 2 Previous Next 15 Replies Latest reply on May 11, 2004 3:57 AM by hxp

    opinion needed for news design

    jae77

      as i've said in previous posts, one of the things i'd like to be able to do w/ the news module is allow it to support multiple news formats - included w/ that would be the ability to define additional fields for input/display.

      that leaves me w/ 2 questions that i'd like to get some general input on...

      1) i was thinking of either allowing ppl to create additional tables that have a fk relationship back to a "basic" story (a basic story defines the base elements that would make up any news format) - or i was thinking that i could just expose a "clob" field on a single table and addtional info for that format could be stored as xml, but this may cause performance problems b/c of the un/marshalling that needs to be done.

      2) reguardless of whatever approach is taken, there are going to be changes to the db schema, and i'm worried about having to deal w/ possible migration issues. what should our overall stance on schema changes be?

        • 1. Re: opinion needed for news design

           

          i was thinking that i could just expose a "clob" field on a single table and addtional info for that format could be stored as xml, but this may cause performance problems b/c of the un/marshalling that needs to be done.


          I strongly vote for this approach. Otherwise, as the module changes over time, you just get more and more tables and business logic. Drive it off a generic table structure + metadata about each news format. My data integration application has this architecture for dealing with different content types. I never have to change my database structures or my code to deal with new content types - configuration data only.

          I don't believe that performance will be that much of an issue, really. I have not found it so, and also look at things like Cocoon.

          there are going to be changes to the db schema, and i'm worried about having to deal w/ possible migration issues. what should our overall stance on schema changes be?


          As long as we are clear what has changed with regard to prior versions, then I don't see a problem with DB structure changes. You could even have a migration script - or someone could contribute one. This problem is one reason for doing the generic DB approach outlined above.



          Sherman

          • 2. Re: opinion needed for news design
            jae77

            thx! i'm definately leaning more towards the generic approach myself. i'd like to avoid migration scripts as much as possible.

            we're using this model w/ castor to handle a similiar issue at the day job. we sell some products that share 75% of the same info, just the product specific attributes change, so why add tables each time you add a product.


            • 3. Re: opinion needed for news design

              My feeling is that the news module has not ever been officially released yet. It has been said it is under development. I don't see any problem with changing the schema at this stage because it is a module under developement.

              My question is how are we going to handle upgrades to nukes and modules when the schemas change for them? I know how postnuke handled them but I don't think we could do somthing like that because we are using cmp.

              • 4. Re: opinion needed for news design
                jae77

                well - i'm pushing towards a release of the news module, but it is only going to be a "1.0" release, which means it won't have a lot of nifty features etc.

                once we it gets released w/ the 1.1 nukes release, i'm not quite sure if it's really "in development" anymore, so making schema changes would be harder.

                if schema changes need to be made in the future, the best bet would be to write some migration scripts to do a dump of the existing data, drop the tables, create the new ones, and parse the data dump into the new table format and load.

                overall, it's not a process that sounds like much fun - but would handle the issue.

                • 5. Re: opinion needed for news design
                  triathlon98

                   


                  My question is how are we going to handle upgrades to nukes and modules when the schemas change for them? I know how postnuke handled them but I don't think we could do somthing like that because we are using cmp.


                  If every DB access uses CMP can this can very simply be done.

                  The DB could automatically be created and updated using the create-table and alter-table configurations in CMP. This would make but installing and updating a breeze. There are some limitations (for the alter-table that is), but they are very workable.

                  Joachim

                  • 6. Re: opinion needed for news design
                    hxp

                    Joachim --

                    You've got it -- pure-CMP is definitely the answer! I've been quietly working on a pure-CMP approach for Nukes; I've already redone one of the modules so that zero DDL/SQL is required, and it works nicely... but I'm waiting to speak up about it till after 1.1 is out and the core developers can catch a breath from the front end stuff (jsr-168, jsp, etc).

                    Once I get the patterns set on how to convert the different categories of *EJB.java files... would you be interested in helping out on converting some of the modules?

                    --Howard



                    • 7. Re: opinion needed for news design
                      triathlon98

                       


                      would you be interested in helping out on converting some of the modules?


                      In priciple I would love to, but I am afraid that time is very limited for me. So limited that while I am very interested in Nukes, I have not been able to do more than just try the 1.0 release (had a custom module and theme for the original beta, and noticed things have improved wuite a lot since then).

                      I will check it out again once 1.1 is out and maybe I can fit it in my work schedule in some way.

                      Joachim

                      • 8. Re: opinion needed for news design
                        hxp

                        Joachim --

                        OK, keep your eyes open for a thread in this forum with the phrase "Pure-CMP" in the title... I'll start it within the next week or two.

                        Since you're short on time (know how you feel; I wear more than a dozen hats myself ;-)) ...I may have a quicky to ask from you... if I haven't gotten around to solving my CMR-xdoclet-unknownpk issue by the time I start the "Pure-CMP" thread.

                        Bye for now,
                        Howard

                        • 9. Re: opinion needed for news design
                          noel.rocher

                          Hi all,

                          XML approach is surely the most dynamic way.

                          Certainly an other CLOB table will be necessary for XSLT data that will describe the rendering process. Something like a "available templates for news rendering".

                          • 10. Re: opinion needed for news design
                            hxp

                            Noel --

                            I agree 99% with your assessment -- and it is certainly applicable to more than just the News module.

                            IMO, the winning formula is to use XSLT templates to transform XML, with the .xsl --- and all other species of .xml --- to be derived dynamically when appropriate, but in general to be stored literally within CLOBs within pure-CMP xdoclet-coded Entities (which in turn sit on top of invisible JBoss O/R mapping, which in turn sits on top of completely-invisible SQL/RDBMS).

                            So the 1% that I differ with you on is simply this: our thinking will be much clearer once we stop talking about "tables" ..... "tables" are at least 2 levels of abstraction lower than where we ought to be thinking.

                            -- Howard

                            • 11. Re: opinion needed for news design
                              noel.rocher

                              Hi Howard,

                              I don't know if I've really understood you.

                              What I think about putting XML and XSL things in tables is that this will simplify a lot the Nukes webapp administration(upgrading, backup, ...).

                              In one project I've used some data out of the database, in files. It was not a really good idea. Neither for administration nor fo security.


                              • 12. Re: opinion needed for news design
                                hxp

                                Noel --

                                "noel.rocher" wrote:
                                Hi Howard,
                                I don't know if I've really understood you.


                                Sorry; I'll do a more complete explanation after the big demo I'm preparing is finished :-)

                                -- Howard

                                • 13. Re: opinion needed for news design
                                  jae77

                                  for the record, i was thinking about using the clob/xml idea to store data in the database, not for any kind of rendering/transformations.

                                  • 14. Re: opinion needed for news design
                                    hxp

                                    Noel --

                                    The demo for my client is now over with, so I can turn my attention back to Nukes backend development... I'm organizing and preparing a bunch of relevant material, and will be posting it in the next few days --- and it will make this whole subject a lot clearer. I'll post back here when there is something relevant to point to.

                                    -- Howard

                                    1 2 Previous Next