You are viewing a plain text version of this content. The canonical link for it is here.
Posted to torque-dev@db.apache.org by Thomas Fischer <fi...@seitenbau.net> on 2010/09/27 21:52:08 UTC
Attibute modifications in schema
Ok, so let me summarize (please object if I misinterpreted somebody)
table.alias:
Noboby thinks that the alias attribute is useful and will be missed. So
I'll create a jira issue for it and we drop it.
table.abstract
I'm of the opinion that the abstract attribute works but Thomas V is of
another opinion. But, thinking about it, we can make it work once the Peer
class is not static any more. So the question is do we think it's useful
and should be kept or should we drop it (This quesion mainly goes to Thomas
V as Greg has already answered it in favour of dropping)
column.inputValidator
Should be dropped but options should be made available in the columnMap.
I'll create a jira issue and implement it.
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
Posted by 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
Posted by 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
Posted by 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
Re: Attibute modifications in schema
Posted by 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
Posted by Christoph Engelbert <c....@u-form.de>.
Am Donnerstag, den 30.09.2010, 11:43 +0200 schrieb Thomas Fischer:
> Hi Christoph,
>
> > I'll like the idea of using POJOs with annotations and I would be glat
> > to see it in Torque as well. This would make things a lot easier since
> > we use interfaces and concrete implementations. These implementations
> > are wrapped by adapter-classes so annotations would be a great success
> > to get rid of those adapters.
> >
> > I'll like to try myself on annotation-driven approach for Torque if more
> > people like the idea.
>
> Speaking on behalf of myself, not on behalf of the Torque community:
> a) the question is how you want to use the annotation. I'd be strongly
> against using annotations at runtime, this is not in the spirit of Torque.
> There are plenty of frameworks around which do this, and this is terribly
> difficult to debug. However, if one uses annotations as just another input
> for the generator (i.e. the generator would scan for annotated classes and
> generates the SQL, Peer classes etc from it), this would be fine with me.
> However, certain restrictions will apply, e.g 1) the annotated classes must
> probably be in the same package, 2) either we must remove the necessity
> that the Torque objects must inherit from BaseObject or the annotated
> classes must inherit from this interface, 3) etc.
The intension wasn't to use Runtime-Annotations since the schema needs
to be build at compile-time (for maven users resource-generation time).
I don't want to change that behaviour since I'm totally agree with it.
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.
> 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.
> But personally, I will not be putting too much work into it. I'll be happy
> to help with any design questions, but I'll definitely not work on the
> implementation.
>
> 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
Re: Attibute modifications in schema
Posted by Thomas Fischer <fi...@seitenbau.net>.
Hi Christoph,
> I'll like the idea of using POJOs with annotations and I would be glat
> to see it in Torque as well. This would make things a lot easier since
> we use interfaces and concrete implementations. These implementations
> are wrapped by adapter-classes so annotations would be a great success
> to get rid of those adapters.
>
> I'll like to try myself on annotation-driven approach for Torque if more
> people like the idea.
Speaking on behalf of myself, not on behalf of the Torque community:
a) the question is how you want to use the annotation. I'd be strongly
against using annotations at runtime, this is not in the spirit of Torque.
There are plenty of frameworks around which do this, and this is terribly
difficult to debug. However, if one uses annotations as just another input
for the generator (i.e. the generator would scan for annotated classes and
generates the SQL, Peer classes etc from it), this would be fine with me.
However, certain restrictions will apply, e.g 1) the annotated classes must
probably be in the same package, 2) either we must remove the necessity
that the Torque objects must inherit from BaseObject or the annotated
classes must inherit from this interface, 3) etc.
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.
But personally, I will not be putting too much work into it. I'll be happy
to help with any design questions, but I'll definitely not work on the
implementation.
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
Posted by Christoph Engelbert <c....@u-form.de>.
Hi guys,
I'm not new to this list but was read only for a long time. At work we
extensively use Torque in one of our bigger projects.
To the dicussionpoint:
I'll like the idea of using POJOs with annotations and I would be glat
to see it in Torque as well. This would make things a lot easier since
we use interfaces and concrete implementations. These implementations
are wrapped by adapter-classes so annotations would be a great success
to get rid of those adapters.
I'll like to try myself on annotation-driven approach for Torque if more
people like the idea.
Greetings from germany
Christoph
Am Mittwoch, den 29.09.2010, 20:43 +0200 schrieb Thomas Vandahl:
> On 27.09.10 21:52, Thomas Fischer wrote:
> > table.abstract
> > I'm of the opinion that the abstract attribute works but Thomas V is of
> > another opinion. But, thinking about it, we can make it work once the Peer
> > class is not static any more. So the question is do we think it's useful
> > and should be kept or should we drop it (This quesion mainly goes to Thomas
> > V as Greg has already answered it in favour of dropping)
>
> I tried to make myself clear in another mail. That said, I have never
> used that attribute and probably won't miss it.
>
> The idea behind the attribute is however interesting. There are quite a
> few other frameworks that generate bean-like classes which could be used
> as Torque objects right away (JAXB comes to mind). I remember having a
> hard time when I tried to adjust the Fulcrum security interfaces to
> Torque objects. Maybe we find a more elegant solution when we rework the
> runtime.
>
> Bye, 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
Posted by Thomas Fischer <fi...@seitenbau.net>.
Thomas Vandahl wrote:
> On 30.09.10 05:24, Thomas Fischer wrote:
> > I would be in favour of dropping the need for "extends BaseObject".
>
> I don't think this is meant to be necessary. The objects only must
> implement Persistent. The schema supports the "baseClass" and "basePeer"
> attributes to achieve this. However, I actually *do* remember that the
> replacement failed because of some braindead assumption in BasePeer. At
> least I gave up when I tried it.
Ok I created a jira issue for dropping this requirement:
https://issues.apache.org/jira/browse/TORQUE-147
I'd be interested in views whether we should retain BaseObject at all.
Please comment in jira.
Thanks,
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
Posted by Thomas Vandahl <tv...@apache.org>.
On 30.09.10 05:24, Thomas Fischer wrote:
> I would be in favour of dropping the need for "extends BaseObject".
I don't think this is meant to be necessary. The objects only must
implement Persistent. The schema supports the "baseClass" and "basePeer"
attributes to achieve this. However, I actually *do* remember that the
replacement failed because of some braindead assumption in BasePeer. At
least I gave up when I tried it.
Bye, 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
Posted by Thomas Fischer <fi...@seitenbau.net>.
> > table.abstract
> > I'm of the opinion that the abstract attribute works but Thomas V is of
> > another opinion. But, thinking about it, we can make it work once the
Peer
> > class is not static any more. So the question is do we think it's
useful
> > and should be kept or should we drop it (This quesion mainly goes to
Thomas
> > V as Greg has already answered it in favour of dropping)
>
> I tried to make myself clear in another mail. That said, I have never
> used that attribute and probably won't miss it.
Ok, but now as I have understood that it is working we can also keep it. No
big pain involved.
> The idea behind the attribute is however interesting. There are quite a
> few other frameworks that generate bean-like classes which could be used
> as Torque objects right away (JAXB comes to mind).
Just to make sure I understand what you are saying this time. You would
- mark the Torque object as abstract
- inherit the JAXB object from the Torque object (thisi s the difficult
part)
- and override the getOMClass method in the Peer class
I do not think this is working because the usual foreign generation
frameworks do not allow for the generated classes to inherit from other
classes. So it must either be the other way round (Torque objects
inheriting from JAXB object), which is currently not possible because
Torque objects need to extend BaseObject (however, in my opinion this could
be changed easily), or to use composition instead of inheritance (create a
new object keeping instances of the two, and delegate calls through), which
sounds difficult as the creation of these composited objects is difficult
to get back in the frameworks.
> I remember having a
> hard time when I tried to adjust the Fulcrum security interfaces to
> Torque objects. Maybe we find a more elegant solution when we rework the
> runtime.
I would be in favour of dropping the need for "extends BaseObject".
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
Posted by Thomas Vandahl <tv...@apache.org>.
On 27.09.10 21:52, Thomas Fischer wrote:
> table.abstract
> I'm of the opinion that the abstract attribute works but Thomas V is of
> another opinion. But, thinking about it, we can make it work once the Peer
> class is not static any more. So the question is do we think it's useful
> and should be kept or should we drop it (This quesion mainly goes to Thomas
> V as Greg has already answered it in favour of dropping)
I tried to make myself clear in another mail. That said, I have never
used that attribute and probably won't miss it.
The idea behind the attribute is however interesting. There are quite a
few other frameworks that generate bean-like classes which could be used
as Torque objects right away (JAXB comes to mind). I remember having a
hard time when I tried to adjust the Fulcrum security interfaces to
Torque objects. Maybe we find a more elegant solution when we rework the
runtime.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org