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 (JIRA)" <ji...@apache.org> on 2006/12/18 13:50:23 UTC

[jira] Commented: (TORQUE-72) Beans should not require torque.objectIsCaching = true setting to create all complexModel methods.

    [ http://issues.apache.org/jira/browse/TORQUE-72?page=comments#action_12459300 ] 
            
Thomas Fischer commented on TORQUE-72:
--------------------------------------

I'm not sure whether the FK get methods make sense without complexObjectModel set to true. If one changes the value of complexObjectModel, the interface of the database objects changes, so why should the interface of the bean objects not change ?

Considering what these methods should do if complexObjectModel is set to false makes this point clear: Currently, if complexObjectModel is set to true, the current bean creation code just takes the lists of cached related objects and stores them in the beans. If they have not been queried yet, nothing is stored, even when related objects exist.
In the bean, one can tell the difference between "was not queried" and "no related objects exist" because the returned list is null in the former case and an empty list in the latter.

So what should happen in the get methods if complexObjectModel is false ? I can see three possibilities
1) query the db on bean creations for the foreign keys and store the results in the beans
2) always return null
3) always throw an exception

1) is not really an option in my eyes. It is contrary to the intent of setting complexObjectModel to false.
2) would always tell "no objects cached". If these methods are added, this would be my preferred implementation.
3) would say "this method is only there for interface compliance reasons". This would be different to the implementation if complexObjectModel is turned on, and thus is in my eyes inferior to solution 2)

Assuming the implementation 2, what would an application do with these methods ? If an application handles the beans only and not the full Torque objects, it has no chance whatsoever to react on the condition "the related object cache is not filled", because the bean has no access to the database and cannot fill the related objects cache istelf. Retrieving the related objects make sense only if one relies on the torque application to fill these fields, otherwise one would not call the method at all. And if a method is not called, why should it exist at all ?

> Beans should not require torque.objectIsCaching = true setting to create all complexModel methods.
> --------------------------------------------------------------------------------------------------
>
>                 Key: TORQUE-72
>                 URL: http://issues.apache.org/jira/browse/TORQUE-72
>             Project: Torque
>          Issue Type: Bug
>          Components: Generator
>    Affects Versions: 3.3
>            Reporter: CG Monroe
>            Priority: Minor
>
> Record Objects generated with complexModel = true will include the get all associated FK records methods, e.g.
>   List books = author.getBooks()
> regardless of the objectIsCaching setting.
> Beans however, will NOT generate the get associated FK records methods unless objectIsCaching is true.
> FWIW, the get related PK object methods are generated, e.g.
>   Author a = book.getAuthor();
> regardless of objectIsCaching.
> The Bean template coding needs to be reviewed and fixed to generate code correctly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

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