About #constructAllTables creating ALL tables
Locked
About #constructAllTables creating ALL tables
 
|
Hi.
-- I found out that #createTables ends up trying to create tables for all #tableFor* method. Sometimes while you are writing the mappings it's common you start testing while not having all table mappings finished and working. I though #createTables would only create the tables for the ones I define in #allTableNames, but it does not.
Otherwise, what is the idea of #allTableNames? The method is constructAllTables "Subclasses can override this method to add tables to the list. But by default we also look for all table methods in our system, and add them to the class list, so if the methods are written there, then we don't need to do anything further. If the table methods are defined on the classes themselves, then we'll still have to construct the list manually."
self allTableNames do: [:each | self tableNamed: each asString]. self constructTablesFromInitializeMethods.
^tables. So my question is if whether the following is more practical/expected: constructAllTables
"Subclasses can override this method to add tables to the list. But by default we also look for all table methods in our system, and add them to the class list, so if the methods are written there, then we don't need to do anything further. If the table methods are defined on the classes themselves, then we'll still have to construct the list manually."
self allTableNames do: [:each | self tableNamed: each asString]. ^tables.
(I removed the line #constructTablesFromInitializeMethods) What do you think? Mariano http://marianopeck.wordpress.com You received this message because you are subscribed to the Google Groups "glorp-group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at http://groups.google.com/group/glorp-group?hl=en. For more options, visit https://groups.google.com/groups/opt_out. |
Re: About #constructAllTables creating ALL tables
|
I think #allTableNames
Was to be depreciated Regrds, @+Maarten ---- Envoyé avec BlackBerry® d'Orange ---- From: Mariano Martinez Peck <[hidden email]>
Sender: [hidden email]
Date: Thu, 6 Jun 2013 16:21:43 -0300 To: <[hidden email]> ReplyTo: [hidden email]
Subject: About #constructAllTables creating ALL tables Hi.
-- I found out that #createTables ends up trying to create tables for all #tableFor* method. Sometimes while you are writing the mappings it's common you start testing while not having all table mappings finished and working. I though #createTables would only create the tables for the ones I define in #allTableNames, but it does not.
Otherwise, what is the idea of #allTableNames? The method is constructAllTables "Subclasses can override this method to add tables to the list. But by default we also look for all table methods in our system, and add them to the class list, so if the methods are written there, then we don't need to do anything further. If the table methods are defined on the classes themselves, then we'll still have to construct the list manually."
self allTableNames do: [:each | self tableNamed: each asString]. self constructTablesFromInitializeMethods.
^tables. So my question is if whether the following is more practical/expected: constructAllTables
"Subclasses can override this method to add tables to the list. But by default we also look for all table methods in our system, and add them to the class list, so if the methods are written there, then we don't need to do anything further. If the table methods are defined on the classes themselves, then we'll still have to construct the list manually."
self allTableNames do: [:each | self tableNamed: each asString]. ^tables.
(I removed the line #constructTablesFromInitializeMethods) What do you think? Mariano http://marianopeck.wordpress.com You received this message because you are subscribed to the Google Groups "glorp-group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at http://groups.google.com/group/glorp-group?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "glorp-group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at http://groups.google.com/group/glorp-group?hl=en. For more options, visit https://groups.google.com/groups/opt_out. |
Re: About #constructAllTables creating ALL tables
|
|
Yes, it was annoying to have to maintain the allTableNames methods separately. But an individual descriptor system can override to do whatever it wants. I have an idea that there's something more pleasant to do than overriding constructAllTables, but I don't have code handy to check right now. I guess you could override constructTablesFromInitializeMethods to be a no-op in your subclass.
On 7 June 2013 04:57, <[hidden email]> wrote:
You received this message because you are subscribed to the Google Groups "glorp-group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at http://groups.google.com/group/glorp-group?hl=en. For more options, visit https://groups.google.com/groups/opt_out. |
«
Return to GLORP
|
1 view|%1 views
| Free forum by Nabble | Edit this page |