Personally I think xdoclet + jdo is as good as possible with the current state of java (untyped collections). How do you propose to specify the type a container object is supposed to contain without additional metadata? How do you propose to specify which classes should be persistent?
Maintaining this type of info outside the java file is ludicrous, therefore it needs to be maintained in the java file. Do you have a better idea than javadoc tags? One of my clients is using xdoclet + 2 jdo implementations and it works fine, even though the xdoclet jdo templates are very new. As with any use of xdoclet, running the xml generation as part of the build assures that it is up to date. In the future we will probably see this kind of metadata stored directly in class files rather than external xml files, but I think it will still be generated from javadoc tags in the source. david jencks On 2003.02.20 17:26 Daniel Shriver wrote: > -----Original Message----- > >> As such writing / > >> changing mapping files everytime the codebase changes is unacceptable; > >> likewise marking up the code with meta-data (which another tool like > xdoclet > >> could use to generate a map) is also unacceptable. > > > > Mhh. Xdoclet is a very elegant mechanism and imposes only minimal > > intrusion into the source code. I would at least think about it... > > Xdoclet could be extremely elegant and impose very little BUT still be > fundamentally > unacceptable. The way I see it is: any such impositions are "invisible" > (don't > expect a compiler or any other standard tool to tell you that you're out > of > sync), > burdensome (every programmer has to keep all the areas to sync up in > mind, > and any > change on relevant data objects necessitates new mappings or > meta-data...), > and a > maintenance nightmare, what if someone fails to update the mapping for a > class that > is sometimes (but seldom) saved off, the bug could go unnoticed (unless > you > have > perfect testing) for a long time. > > Right now there's a plethora of tools (to improve on Java's > serialization) > but most > of the ones that seem to have a good community (OJB, Castor, Hibernate) > have > this > mapping issue. There are also a number of commercial solutions, BUT, the > market > seems rather fragmented and (as such) I find it dubious that the > commercial > solutions > are really turn-key (as many claim to be). > > > If want to use a standardized mechanism your code must stick to some > > conventions. Otherwise you need AI :-) > > I certainly hope it doesn't go as far as AI (but then again AI is pretty > nebulous). It > looks like a difficult problem but one that probably does have some > reliable > algorithms > (rather than flaky heuristics) to solve it. The collection "mess" is one > of > the most > difficult issues (what to do with amorphous collections like Vector). > What > I'm hoping for > is to create an "automatic mapping" standalone, and this could be > configured > to make > different mapping behaviors/assumptions. > > Given the number of solutions like OJB, Castor, and Hibernate is there > some > way that a hybrid > community could be made (I've seen people take stabs at this auto-mapping > problem before, > it doesn't look like I'm the only one who is concerned with it) to > implement > the "other > half" (an auto-mapping program, which takes an input meta-map that > defines > the structure and assumptions for mapping). > > > You can allow to Reflection to access everything. > > Ok, that's going to be my approach. > > > IMO these are all viable solutions. > > But you always face some tough questions to answer: > > Most aren't so tough for me, but if I want to contribute to a mapping > program that can help > others (OJB, Castor, Hibernate,....... future tools) I need to make this > flexible and > configurable. > > > 3. how to handle collection attributes? > > java collections are not typed. that is you don't know the element > > type of a collection! How will you tell OJB which element-class a given > > > collection-descriptor will have?! > > That is the UGLY issue. Aside from Collections the other problems (such > as > arbitrary classes > with inner and anon classes...) seem like they should have a solid > solution > (even if it is > some really annoying recursion...) > > > 4. how to identify foreign key elements if there are multiple > > associations between classes?! > > Say class A holds two collections of B elements. B will then have two > > foreignkey attributes. one for the first collection, one for the > second. > > How can you know which FK to use for which collection?! > > This is another possibly painful problem. > > > etc. etc. > > Without answering these questions you are lost. IMO the only viable > > solution is to have clear code-conventions that allow automated > > detection of the mentioned stuff. > > That would be ideal, but proposing to rewrite all our code (and 3rd party > code) to fit some > nice convention, would never fly at this company (or most other ones). > Real > codebases always > have some "ugliness" factor. My feeling is that things like data > serialization need to be near > automatic (not imposing maps or meta data), and general (not imposing a > coding convention) to > be truly useful. > > Thanks for your thoughtful input. > > Again, does anyone have an idea for how to build a community for working > this problem out? I > am thinking along the lines of something like OJB, Castor, Hibernate- an > open source solution > with multiple participants. A flexible mapping tool could (potentially) > be > plugged into all > three of these code/storage solutions (as well as others). > > cheers, > Thomas > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
