[prev in list] [next in list] [prev in thread] [next in thread] 

List:       turbine-torque-dev
Subject:    [jira] Commented: (TORQUE-72) Beans should not require
From:       "Thomas Fischer (JIRA)" <jira () apache ! org>
Date:       2006-12-18 12:50:23
Message-ID: 60529.1166446223267.JavaMail.jira () brutus
[Download RAW message or body]

    [ 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


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic