1 2 Previous Next 19 Replies Latest reply on Feb 22, 2004 7:24 PM by jae

    Next Nukes Release ?

    Nicholas Whitehead Novice

      When will the next Nukes release be out ? Will it be a version that runs on Oracle 9 out of the box ?



        • 1. Re: Next Nukes Release ?
          jae Master

          the 1.0 release is coming very soon, however there is no support for oracle at this moment.

          • 2. Re: Next Nukes Release ?
            Nicholas Whitehead Novice

            Thanks ! Looking forward to it.
            What databases will be supported ?

            • 3. Re: Next Nukes Release ?
              jae Master

              mysql - i think postgress may also be supported, but i am not sure how far along the porting process of the create db scripts is.

              if you need oracle support, perhaps you could create a ddl for oracle. just use the mysql ddl to get the schema.

              • 4. Re: Next Nukes Release ?
                Nicholas Whitehead Novice

                Cool. Can I get the DDL in CVS ? I will translate and post.

                Also, not to be a pain in the ass, but why is there database specificity in Nukes ? Is it not using CMP2 or Hibernate or something ?

                • 5. Re: Next Nukes Release ?
                  jae Master

                  nukes isn't tied to any database - it's just that only ddl's have been written for mysql, hdbsql, and postgress(?)

                  for each module that uses the database, you should find a ddl somewhere in it's resources directory.

                  • 6. Re: Next Nukes Release ?
                    Howard Pearlmutter Novice

                    Hi Jae,

                    Could you please go deeper into Nicholas' question, and clear something up for those of us who are curious...

                    Why is there any need for DDL at all?

                    Is the DDL, which was in the .ddl files and is now embedded in the setup.xml files, a legacy of the database schema migration from the PHP Nukes model?

                    Will it eventually be eliminated when Nukes takes full advantage of EJB2.0 CMP ??

                    Or, is there something that you guys have discovered that is outside what CMP can handle? ...that has to be done via a SQL/DDL approach? What are the particular database-specific issues that have to handled separately for each database?

                    What is the rationale for not using J2EE standard facilities to manage table creation (and possibly removal)? Why do we have these xdoclet tag values:

                    * @jboss.persistence
                    * create-table="false"
                    * remove-table="false"

                    Why not go thru CMP to establish the DB? ....instead of .ddl, or embedded sql inside setup.xml, why not just have a utility to read nice clean XML (i.e., with no embedded SQL), and then go properly thru entity EJBs w CMP to create everything in the DB?

                    BTW, a side effect of the above approach is that it would get us pretty far towards a powerful admin facility -- batch construction, under-the-hood maintenance, dump & reload of the entire Nukes database to pure XML... so IMHO, it would be a good way to go anyway. So why not initialize the system this way?

                    Perhaps this is the plan, and we're just not there yet? Or what am I missing?

                    • 7. Re: Next Nukes Release ?
                      jae Master

                      unfortunately, i am going to have to defer these questions to julien.

                      i've only recently joined the effort and come from an environment that doesn't do table creation through the entity beans, so i've honestly never thought about it.

                      how fine grained are the database constraints if you use the entity bean to create the table?

                      • 8. Re: Next Nukes Release ?
                        Viet Master

                        Unfortunately create/remove table were not good enough when we started the project.

                        We need index on some fields and at this moment it was not possible to add index constraint on the cmp fields (now it is possible)

                        • 9. Re: Next Nukes Release ?
                          Howard Pearlmutter Novice


                          CMP & CMR are designed to meet the needs of fine-grained financial IT apps, and my guess is that the needs of a CMS like Nukes wouldn't push the envelope. How fine grained do you want?

                          JBoss surely handles constraints like Check (column type), NotNull, Primary Key, ForeignKey/Reference; I'd have to dig a bit to say for sure about the Unique constraint (no duplicates in a column) & Index.

                          But, personally, my hunch is that in the end it won't be a problem no matter what granularity of constraint is required, and here's why:

                          Database constraints are about enforcing basic business rules; and EJBs are all about business logic/rules. We're talking constraints because we care about data integrity and referential integrity...and the key insight is that the constraints that really matter are the ones in the App Server, rather than the Database Server.

                          Business logic lives in EJB. EJB knows more about the data than the DB ever will. Java's type system is far more sophisticated than the SQL type system; as a strongly typed language, Java can impose far finer constraints.

                          With CMP we can use the EJB constainer to take care of the integrity of the data. With CMR we can use the EJB container to take care of the integrity of the relationships.

                          The new way to think about things is that the center of the universe is J2EE (JBoss), not the persistent store (RDBMS). The DB really should be seen increasingly as just a place to persist the data when it's passive; what really matters is when the data is active as objects living in the cache.

                          OK, it's possible to enforce rules through "application" or "database"...
                          A common misconception is that "since tables can be accessed via DB utilities and other apps (bypassing the application checks), database-level enforcement via constraints provides a better solution."

                          Well, IMHO, JBoss Nukes is a "greenfield"; no other app has access to the DB. This is no legacy integration deal; it's a fresh start and we can do it the right way. Nukes should own the DB; 100% of all DB access should go thru JBoss (even tho that might look like a distributed cluster of numerous JBoss instances in some ISP farm a few years from now).

                          But even if Nukes didn't own the database, and has to share it with other apps: the better practice is to enforce rules through infrastructural contracts.

                          J2EE provides a whole slew of infrastructural contracts, from the low levels of JCA up to the high levels of EJB CMR.

                          (look at JCA to understand about system level contracts (Connection, Transaction, Security); look at org.jboss.ejb.plugins.cmp.jdbc.JDBCTypeComplexProperty to see datatype mappings; look at EJB 2.0 CMP & CMR for the higher level contracts regarding data integrity & referential integrity.)

                          I like the way Marc Fleury expressed it in his BLUE paper (“Why I Love EJBs”):
                          'Ok, so you understand that caches in memory, alongside with your other logic, are the simplest way to build fast J2EE applications. Now the natural question is “how do we put data in these caches”. Well, today there is very little need to use your own database access code. This is another nail in the coffin of the retrograde servlet to jdbc designs. The new persistence framework, specified in EJB 2.0 is so powerful it should really be a standalone spec. We will talk more about that in the RED paper. It is that silver bullet we were looking for in serverside persistence. For those of you who don’t know what it is, CMP stands for “Container Managed Persistence” and this is the age-old promise of automated mapping from the object domain to the database realm. To automate the persistence is simple in simple cases and quite complex for everything else. The first version of the persistence, the 1.1 version, was seriously lacking in various critical aspects. The 2.0 version is however a blockbuster. It comes with Container Managed Relationships, which let the container take care of the integrity of the relationships. The addition of the abstract getters and setters offers another great feature. It is the responsibility of the container to implement these. The nice part is that the container can now follow with great granularity what data you access and what data you write, thereby tracking most of the information it needs to optimize your data access patterns. What this means is that a lot of the optimizations we needed to do by hand in the 1.1 version are now automatically taken care of for you in the container. If you are only reading a bean, we know it, if you are not modifying all the fields we know it, if you are going to load certain data sets for certain methods, we know it since you can give hints to the persistence engine and help it optimize the loading and storing time. One of the interesting things we are seeing with CMP2.0 is that everyone is dropping BMP for CMP. BMP is a fancy word for “JDBC by hand” and was the old way of letting you code your data access layer methods in the body of an EJB. Today, almost no-one uses BMP anymore as the power of CMP is proven and working.'

                          Indeed, "Cache is King", and if your contracts with the world outside the cache have integrity, then your cache can handle the rest.

                          It feels like every month JBoss is making progress toward achieving a truly transparent object persistence framework (which is a big reason why i've been tracking (and applauding) that progress since '99).... it may not be at the holy grail quite yet, but then again, what do you really need in order to support the requirements of Nukes?

                          My starting guess was that JBoss already had all the support that Nukes would need, which is why I've been scratching my head trying to figure out why there's all this DDL cruft... trying to figure out where's the hole in my CMP knowledge...

                          So thanks, Julien, for giving us the scoop:

                          Unfortunately create/remove table were not good enough when we started the project.

                          We need index on some fields and at this moment it was not possible to add index constraint on the cmp fields (now it is possible)

                          My hunch about JBoss/CMP having everything necessary was right..... perhaps a bit optimistic for when the project was begun... but quite reasonable now...

                          So that gives me some encouragement to put in a plug for the benefits of doing Nukes the right way --- (all interaction with DB via pure CMP2.0; data checking via code in entity EJBs plus what CMP2.0 does automatically for us):

                          Doing it right will reduce the complexity of intalling Nukes at least 3:1 ... which means boosting the installation success rate and applying more eyeballs to finding real application bugs.

                          Doing it right will reduce the number of "how do i get started" forum posts, less time for the active coders to waste answering the same questions over and over on the forums.... increase the number of active users, increase the number of happy users, and increase the number of contributors.

                          Doing it right will make it much easier and cleaner not only to install, but also uninstall, leading to more willingness to upgrade and check new CVS snapshots more frequently.

                          Doing it right will give us nice side effects of providing the hooks needed for batch construction, under-the-hood maintenance, plus dump & reload of the entire Nukes database to pure XML. (I'll volunteer to help with writing the xml dump/(re)load utility.)

                          Doing it right will show off what JBoss has to offer, be a real good reference for people doing apps on top of JBoss, and be a good proof-of-concept for what Marc wrote in his BLUE paper.

                          And I'll even go so far as to make myself unpopular with everyone wanting instant gratification: I vote for delaying a general release until the database-specific ddl stuff is removed from setup.xml, and replaced with initialization data embedded in regular old XML elements, and the DB tables are all created thru CMP. For the longterm good of the Nukes project, it would be good to have a schema that we can be backwards-compatible with. Risk of a future "gotcha" will be reduced when we know that we are indeed generating, via CMP, a schema we can live with for a good long while.

                          • 10. Re: Next Nukes Release ?
                            Viet Master

                            We only use index speed up queries and relationship traversal, no other constraint, Nukes owns the database.

                            For instance you will see speed difference in findByUserName on UserEJB wether you put or not an index constraint on that field. Etc....

                            Except that we don't use database constraints.

                            • 11. Re: Next Nukes Release ?
                              Andrew Oliver Master

                              I didn't read your whole message as it was bit long. However, I think nukes needs to become easier to install. Removing the DDL is a major part of that. I don't think it should hold up the first release, but on the other hand first impressions... It might be chill to see Nukes use hibernate instead of JBossCMP.

                              • 12. Re: Next Nukes Release ?
                                jae Master

                                i was actually going to ask julien if there were future plans to switch to hibernate. i don't disagree that we should move away from the DDLs, but that may not be the highest priority item to deal with right now.

                                however, right now the development effort on nukes is pretty small and there is a lot of work that needs to be done. julien is the only full time person on this, i've got a day job and can only contribute at night (and even then only a couple nights a week), so things are going to move slowly until more help decides to join in.

                                if anyone would like to see this effort accelerated, then start writing patches and contribute back to the project.

                                • 13. Re: Next Nukes Release ?
                                  Viet Master

                                  no plans for hibernate, there are other priorities.

                                  • 14. Re: Next Nukes Release ?
                                    Heiko Rupp Master


                                    how fine grained are the database constraints if you use the entity bean to create the table?

                                    Besides what Julien already said, with the post-table-create feature you can basically have whatever you want (which is db-dependent, but if you use sql92, you should be on the safe side).

                                    1 2 Previous Next