Re: Attibute modifications in schema

[Thomas Fischer <fi...@seitenbau.net>]

> ...
> About the problem with inheritance I guess there needs to be some
> discussion. There would be one way which possibly most people around
> here do not like, that would be bytecode enhancement after compilation.
> Since this would be some kind of religious war I'm open to other
> possibilites.
>
> I would like to see some discussion on that topic.

My personal goal would be to remove te necessity to inherit from
BaseObject. If anything like it is required, the object should rather
implement an interface.

> > b) I would welcome an annotation-based approach. I do not think
> > implementation would be too difficult given the 4.0 generator
> > implementation, it would mean to implement just another
> > org.apache.torque.generator.source.SourceProvider (there are already
two of
> > them). Of course some design questions need to be splved, which might
be
> > difficult in detail, but the implementation to the generator is
> > straightforward.
>
> I would try to implement a SourceProvider in the first stage after there
> was some discussion, enough interest and a basic concept how to
> implement it.

Personally I'm not interested, I'd rather edit an XML file than annotate
classes. Others? You can also ask at the users list.

I have thought a bit about the AnnotationSourceProvider class. It could be
split in two parts:
- A general AnnotationSourceProvider which reads annotated classes (this
would be in the generator). It would have an annotation processor
configured in, which translates the annotations to a source tree.
The annotationProcessor interface would also live in the generator. It
would get e.g. a list of annotated classes which themselves contain the
annotated methods (and members, but personally I do not think annotating
members is a good idea) and would be responsible to create a source tree
from the annotated classes. General helpers (e.g. add all annotation
attributes as attributes of an elment in teh source tree) would also live
in the generator.
- The annotation processor and the specific annotations would be part of
the templates.

    Thomas


---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org

Re: Attibute modifications in schema

[Christoph Engelbert <c....@u-form.de>]

> I'm not sure. JPA entities differ in behaviour from Torque objects very
> much We could use only a subset of JPA annotations (e.g. manytomany is not
> supported). Foreign keys concepts differ (Torque objects do know the
> foreign key plus the linked object, JPA objects only know the linked
> object). Besides, the licensing situation might be difficult (I did not
> check the JPA API license). I'd guess JPA annotations will either not work
> at all or prove very difficult to use.
> I do not understand the JAXB part. Torque annotations will be about
> database specifics (which columns will be written into the database, which
> colum is the primary key) and these concepts are not covered by JAXB.

I don't want to copy the JPA behaviour in Torque but since there are
annotations for tables, columns, datatypes ... you can annotate
fields the same way you use in JPA. ManyToMany is first introduced
in JPA 2.0 and for sure the behaviour is totally different but you
can use the annotations as a hint on how to convert the pojos to an
database schema, JPA does it as well.
And for sure it can be a subset of all of the annotations.
The same applies to JAXB annotations. There are annotations for
Elements (e.g tables) and Attributes (columns) - just as an example.

If non of both annotation sets are able to meet the requirements you
can add new annotations (similar to what hibernate or eclipselink
did for missing features of JPA 1.0).

But I would start on an already existing set of annotations to not
overload a pojo with annotations. One field with 20 annotations
isn't easier to handle than writing the xml :)

---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org

Re: Attibute modifications in schema

[Thomas Fischer <fi...@seitenbau.net>]

> >> I would try to implement a SourceProvider in the first stage after
there
> >> was some discussion, enough interest and a basic concept how to
> >> implement it.
>
> It would be (in my opinion) a nice possibility if Torque would use
> the same annotations as JPA or JAXB. So there can be one class for
> both persistence situations. Especially in times where webservices
> grow and they are often implemented by Spring and other JAXB using
> implementations.

I'm not sure. JPA entities differ in behaviour from Torque objects very
much We could use only a subset of JPA annotations (e.g. manytomany is not
supported). Foreign keys concepts differ (Torque objects do know the
foreign key plus the linked object, JPA objects only know the linked
object). Besides, the licensing situation might be difficult (I did not
check the JPA API license). I'd guess JPA annotations will either not work
at all or prove very difficult to use.
I do not understand the JAXB part. Torque annotations will be about
database specifics (which columns will be written into the database, which
colum is the primary key) and these concepts are not covered by JAXB.

> ...


---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org

Re: Attibute modifications in schema

[Christoph Engelbert <c....@u-form.de>]

 Am 01.10.2010 16:23, schrieb Thomas Fischer:
>> ...
>> About the problem with inheritance I guess there needs to be some
>> discussion. There would be one way which possibly most people around
>> here do not like, that would be bytecode enhancement after compilation.
>> Since this would be some kind of religious war I'm open to other
>> possibilites.
>>
>> I would like to see some discussion on that topic.
> My personal goal would be to remove te necessity to inherit from
> BaseObject. If anything like it is required, the object should rather
> implement an interface.
>
>>> b) I would welcome an annotation-based approach. I do not think
>>> implementation would be too difficult given the 4.0 generator
>>> implementation, it would mean to implement just another
>>> org.apache.torque.generator.source.SourceProvider (there are already
> two of
>>> them). Of course some design questions need to be splved, which might
> be
>>> difficult in detail, but the implementation to the generator is
>>> straightforward.
>> I would try to implement a SourceProvider in the first stage after there
>> was some discussion, enough interest and a basic concept how to
>> implement it.

It would be (in my opinion) a nice possibility if Torque would use
the same annotations as JPA or JAXB. So there can be one class for
both persistence situations. Especially in times where webservices
grow and they are often implemented by Spring and other JAXB using
implementations.



> Personally I'm not interested, I'd rather edit an XML file than annotate
> classes. Others? You can also ask at the users list.
>
> I have thought a bit about the AnnotationSourceProvider class. It could be
> split in two parts:
> - A general AnnotationSourceProvider which reads annotated classes (this
> would be in the generator). It would have an annotation processor
> configured in, which translates the annotations to a source tree.
> The annotationProcessor interface would also live in the generator. It
> would get e.g. a list of annotated classes which themselves contain the
> annotated methods (and members, but personally I do not think annotating
> members is a good idea) and would be responsible to create a source tree
> from the annotated classes. General helpers (e.g. add all annotation
> attributes as attributes of an elment in teh source tree) would also live
> in the generator.
> - The annotation processor and the specific annotations would be part of
> the templates.
That sound very similar to the first intentions I had about how to
implement the SourceProvider.

About the users mailinglist, I'll add myself and start a discussion
about it.

>     Thomas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-dev-help@db.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org