You can get a Column[] from a FieldMapping and ask the first Column (there should be only one for a String column) for its size.
-Patrick On Feb 7, 2008 8:52 AM, David Goodenough <[EMAIL PROTECTED]> wrote: > OK, I realised that I could specify a CodeGenerator to ReverseMappingTool > and so I am writing my own CodeGenerator. > > I can do most of what I want, but one thing (currently) eludes me which > I used to do in the sql2java templates, but I can not see how to do it > here. > > When I bind a field to a screen widget, I want to be able to set the > maximum length of the string (in the case of a string) so that I can > stop the user entering more than the maximum number of characters (I > would much rather stop him at source than put up an error message saying > too big). It also means that I can set the field physical widths correctly. > > In sql2java I could find the SQL length of the field, and > use that, but I can not seem to find that information anywhere. It is > probably hidden in the FieldMetaData somewhere, but I can not spot it. > > Anyone familiar enough with FieldMetaData to know where I might get this > kind of data. I suppose this also would allow for more general validation > constraints that the DB is going to require to be reflected in the UI but > for the moment the field length (for strings) would be just dandy. > > I want to be able to generate static fields derived from the field name > (so if there was a field call customer then the generated field would > be:- > > public static final int customer_length = 10; > > so that I can use them in my application. I am already generating static > Property objects (given the lack of property support in the compiler yet), > so this will complement this along the way. > > David > > > On Wednesday 06 February 2008, Patrick Linskey wrote: > > Hi, > > > > Neither are available currently, but both sound useful. > > > > For superclass specification, you'll want to change > > ReverseMappingTool.java:1017 and basically copy the > > 'setPackageName(String)' code (including the changes to the Flags > > inner class and the usage in the run method, called from main). > > > > I'm not familiar with the changes you'll need for property change > > support, so can't provide much help there. But again, you'll want to > > add a flag to configure whether or not to generate classes with > > property change support, and then presumably do something different > > when generating setter method bodies. If you can post what you'd like > > a simple class to look like, I might be able to provide a couple of > > pointers. > > > > -Patrick > > > > On Feb 6, 2008 11:05 AM, David Goodenough > > > > <[EMAIL PROTECTED]> wrote: > > > Craig, > > > > > > So do I take it that that neither of these are possible with the current > > > code? > > > > > > David > > > > > > On Wednesday 06 February 2008, Craig L Russell wrote: > > > > Hi David, > > > > > > > > I can't point you to the code offhand, but we're always looking for > > > > contributions that make OpenJPA easier (or in your case even possible) > > > > to use. > > > > > > > > Craig > > > > > > > > On Feb 6, 2008, at 3:04 AM, David Goodenough wrote: > > > > > I recently came across OpenJpa, and it looks like it might be a good > > > > > fit > > > > > for my application (well actually I have a number of similar apps). > > > > > I had > > > > > previously looked at using Sql2Java but that is not following > > > > > standards > > > > > (JPA) and as a project seems to be come and go. > > > > > > > > > > But on first inspection there were a couple of things that I could > > > > > not work out how to do, mainly with ReverseMappingTool (I have > > > > > existing DBs > > > > > to use). > > > > > > > > > > 1) I need the beans that are generated to have PropertyChange > > > > > support, but I can not find an option that enables this. Although I > > > > > am not using this > > > > > in an EJB environment, given that EJBs are a large part of openjpa's > > > > > existance this seems odd. I actually need PropertyChange support as > > > > > I am > > > > > using BeansBinding (JSR-296). > > > > > > > > > > 2) I need the ability for the generated bean to be declared as > > > > > extending > > > > > an existing class. > > > > > > > > > > Now with both of these I could go in and modify the generated source > > > > > code > > > > > myself, but in at least one case I have around 100 tables and the > > > > > thought > > > > > of this not being an automated process is not good. > > > > > > > > > > If neither of these are possible in the existing code, is there any > > > > > objection to my adding both of these and submitting a patch? If > > > > > this is > > > > > the route I am to follow, can anyone point me in the right direction > > > > > as to > > > > > where to look for the bits of ReverseMappingTool that generate the > > > > > getters and > > > > > setters, and generate the class header? > > > > > > > > > > David > > > > > > > > Craig Russell > > > > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > > > > 408 276-5638 mailto:[EMAIL PROTECTED] > > > > P.S. A good JDO? O, Gasp! > > > -- Patrick Linskey 202 669 5907
