[
https://issues.apache.org/jira/browse/TRB-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15405831#comment-15405831
]
Georg Kallidis commented on TRB-98:
-----------------------------------
of course it´s true, Torque (and turbine!) is flexible enought and may be
things getting better - if I follow discussion in TORQUE-343 ;-) "to query the
Torque instance for the PeerImpl class for a given OM class." - will be
supported. This would help a lot (to get rid of code in Fulcrum Security Torque
module). Nevertheless it´s up to now dependent on internal OM objects, if the
user doesn´t or wants not regenerate it, e.g. with its own schema - as I
understand it.
Having said that, Torque itself is nevertheless a trustworthy and light
weighted ORM-Mapper and I would stay with it.
I think explicitely defining the database name within Fulcrum Security could
and should removed now entirely (this would have been only a temporary solution
in any case), I´ll update the module once again. The benefit has been somewhat
marginal (it should have allowed, if implemented properly, dynamic setting of
database eg. in Security Torque/Turbine abstract classes dependent of
PeerImpls, which is, what hopefully the intention of Torque-343 is about.
> Fulcrum Torque
> --------------
>
> Key: TRB-98
> URL: https://issues.apache.org/jira/browse/TRB-98
> Project: Turbine
> Issue Type: Improvement
> Components: Fulcrum
> Affects Versions: Core 4.0-M2
> Reporter: Georg Kallidis
> Assignee: Georg Kallidis
> Fix For: Core 4.0 Final
>
>
> The separation of security component from Turbine to Fulcrum Security has one
> backdraw. The component contains generated classes and as the schema is hard
> coded (database name fulcrum, table names fulcrum_turbine_user, etc.) - if
> you don´t care about the abstract classes it would not matter - but as the
> interface hierarchy is more complex now than before
> (TorqueAbstractSecurityEntity etcetera), one would really like to have those
> convenience classes ready at hand, especially in at least one context more:
> The old Turbine schema, which was removed after Turbine-M1, which could be
> found before in turbine/src/torque/schema/torque-security-schema.xml.
> I would recommend to have generated classes according or very similar to this
> old schema with appropriate abstract classes. Configuration of managers could
> be made a little more generic removing import statements of special classes,
> and renaming others, but those abstract classes could not. It is done quite
> easily, but gets a little more similar generated code, but you have not break
> your head about, why it doesn´t match. Suggestions for naming? I would just
> remove the Torque at the beginning.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
