14 Replies Latest reply on Jul 25, 2003 12:20 PM by Steve Lewis

    JBossDO Contributions

    Matt Corey Newbie

      (Moved this over to the development forum from the user forum before it gets to deep :) )

      Alex,

      In the other thread, you mentioned id generators, schema generation and enhancer as possible tasks that don't touch the core too much...

      What work needs to be done on id generators? I noticed briefly that two already exist (HiLo and UUID, if I remember correctly) -- do these need work, or do you have additional generators in mind?

      m

        • 1. Re: JBossDO Contributions
          Alexey Loubyansky Master

          You chose the one that is chosen already :) The guy is currently working on something other and promised to get back to it. I'll write him to clarify.

          Current implementations are really simple. HiLo uses one table with one field and produces only java.lang.Integer IDs. I'd like to have other implementations like the table with columns for sequence name and IDs themselves.
          Also this service should be dynamically and easily configurable, i.e. adding/removing sequences, reseting sequences, changing other parameters, etc.

          I haven't thought enough about it yet, but, definitely, this is the area that needs improvements.

          alex

          • 2. Re: JBossDO Contributions
            Matt Corey Newbie

            If the original author is off working on another challenge, I'd be more than happy to help enhance the HiLo generator with the changes you mentioned. I'm fairly new to JBoss development, but I took a look at the code, and it should be something I can get my feet wet with.

            Let me know if the original auther is willing to give it up, and I'll see what I can do :).

            m

            • 3. Re: JBossDO Contributions
              Bruce Newbie

              I'm the guy who was going to work on the key generators. I was going to implement a sequence key gen and possibly others. We can certainly work together on this if you're willing.

              Bruce

              • 4. Re: JBossDO Contributions
                Matt Corey Newbie

                Sounds good. I can certainly do the implementation of a sequence key generator without too much trouble. I think Alex pretty much summed up how this should work in a previous post -- pretty standard, really.

                If you have any ideas about how to make it dynamically configurable, resetable, etc., I'd be happy to hear them (I was planning on making it work first :) ).

                m

                • 5. Re: JBossDO Contributions
                  Bruce Newbie

                  Agreed. I'm the lead developer for Castor JDO and it already provides a few key generators. Take a look here to see what Castor supports:

                  http://www.castor.org/key-generator.html

                  This might give us a few ideas.

                  Making it dynamically configurable shouldn't be too difficult. I believe the runtime configuation should take place in a config file for JBossDO. We'll need to dig into JBossDO to figure out what config files are available so that we can determine the best location for the configuration metadata.

                  Bruce

                  • 6. Re: JBossDO Contributions
                    Matt Corey Newbie

                    Currently the HiLo- and UUID-Generators are configured as separately installed components, and referenced by JNDI name in the *.jdo files. Since this will be used with the whole 'generic' persistence package, and not just JBossDO, it seems to me that it should remain separate, so that it can be used with CMP, etc (when it eventually gets ported over)

                    BTW - I mentioned earlier I was going to work on the 'Sequence' generator... I should clarify this, I was going to work on the HiLo improvements -- I see that you use the term Sequence for a different kind of generator in Castor...

                    m

                    • 7. Re: JBossDO Contributions
                      Alexey Loubyansky Master

                      I think generators should not be bound JBossDO. Let's implement them as services and deploy with *-service.xml or *.sar. That way they can be used by other projects/applications.

                      Thanks,
                      alex

                      • 8. Re: JBossDO Contributions
                        seanhager Newbie

                        It sounds like JBossDO is going to only run as a deployed unit of the JBoss server.

                        One of the featues that is nice about JDO is that you can write JUnits which test business logic in JDO classes and you don't have to deploy them to a server, which also means you don't have to write a facade test class to get access to them.

                        sean.

                        • 9. Re: JBossDO Contributions
                          Bruce Newbie

                          I agree with Alex's statement that the key generators need to stand alone. The key generators aren't something that should only be available to JBossDO. They need to be generally available.

                          I'm currently unable to access the anonymous CVS because it's down. So I'll need to grab the daily tarball to begin analyzing the JDO code base. Hopefully I'll be able to do this late tonight.

                          Bruce

                          • 10. Re: JBossDO Contributions
                            Bruce Newbie

                            Sean,

                            Alex has indicated that JBossDO may eventually be capable of running in a non-managed environment, but this goal is very low priority:


                            http://www.theserverside.com/home/thread.jsp?thread_id=20171&article_count=110#88023

                            Bruce

                            • 11. Re: JBossDO Contributions
                              seanhager Newbie

                              Thanks for the response Bruce.

                              I think most of us can live with JBossDO only running in a managed environment. It would just be a nice bonus and time saver.

                              I didn't realize that thread was on the server side. There are some interesting debates in there.

                              sean.


                              • 12. Re: JBossDO Contributions
                                Steve Lewis Expert

                                I just posted on the user and found this thread :) go corey.

                                What package are you going to be using for schema generation? What piece of code will you be using to generate the schema? The POJO itself or a stored in-memory representation of the POJO->database (as in POJO + some XML)?

                                I for one am very interested in the external JBossDO implementation, for nothing other than testing outside of the container.

                                Bruce, are you a commiter to cvs yet? I think it's very good that JBossDO has such great people working on it. Castor got very good press but for whatever reason people were scared of Turbine.

                                Steve

                                • 13. Re: JBossDO Contributions
                                  Bruce Newbie

                                  No, I'm not a committer yet on JBoss. We'll see what the future holds before I go that far. I don't follow your comments regarding Turbine? Turbine is a web application framework. Do you mean Torque? Torque actually is part of the top level Apache DB project now:

                                  http://db.apache.org/torque/

                                  Bruce

                                  • 14. Re: JBossDO Contributions
                                    Steve Lewis Expert

                                    Ah yes. That's my mistake. Torque. :) Sorry. From what I gathered even from the turbine people was that it never really took off to the level they wanted. I could be wrong, this is just the gist of things I got once. Things may have changed.

                                    Steve