I've added a Pharo 7 version, copied the configurations from DBXTalk/Glorp to DBXTalk/Configurations and the metarepos, and replaced the #'Pharo6.0.x' style names by #'Pharo6.x' style. Please let me know if that creates problems Stephan
Tx stephan On Wed, Oct 4, 2017 at 5:20 PM, stephan <stephan@stack.nl> wrote:
I've added a Pharo 7 version, copied the configurations from DBXTalk/Glorp to DBXTalk/Configurations and the metarepos, and replaced the #'Pharo6.0.x' style names by #'Pharo6.x' style. Please let me know if that creates problems
Stephan
On 4 Oct 2017, at 17:20, stephan <stephan@stack.nl> wrote:
I've added a Pharo 7 version, copied the configurations from DBXTalk/Glorp to DBXTalk/Configurations and the metarepos, and replaced the #'Pharo6.0.x' style names by #'Pharo6.x' style. Please let me know if that creates problems
Stephan
I tested with the latest ConfigurationOfGlorp-StephanEggermont.61 in Pharo 7 and that seems OK (not super clean, but OK). Thx.
Sven Van Caekenberghe wrote:
On 4 Oct 2017, at 17:20, stephan<stephan@stack.nl> wrote:
I've added a Pharo 7 version, copied the configurations from DBXTalk/Glorp to DBXTalk/Configurations and the metarepos, and replaced the #'Pharo6.0.x' style names by #'Pharo6.x' style. Please let me know if that creates problems
Stephan
I tested with the latest ConfigurationOfGlorp-StephanEggermont.61 in Pharo 7 and that seems OK (not super clean, but OK).
Thx.
Any chance of incorporating fixes 127 / 129? Herby
On 06-10-17 17:22, Herby VojÄÃk wrote:
Any chance of incorporating fixes 127 / 129?
Sure, as soon as someone tells me they are safe to add. I am just testing Glorp with P3 and Postgres now, and don't have the capacity to verify these changes other than by just reading the delta. Stephan
stephan wrote:
On 06-10-17 17:22, Herby VojÄÃk wrote:
Any chance of incorporating fixes 127 / 129?
Sure, as soon as someone tells me they are safe to add. I am just testing Glorp with P3 and Postgres now, and don't have the capacity to verify these changes other than by just reading the delta.
Stephan
127 is general, is not sqlite-specific. Fixes any case where primary key is not primitive and has converter.
stephan wrote:
On 11-10-17 20:33, Herby VojÄÃk wrote:
127 is general, is not sqlite-specific. Fixes any case where primary key is not primitive and has converter.
Should 127 and 129 be merged first, and should current development be promoted to release? And why is 128 missing?
Stephan
129 is from different author, who skipped upload of its 127 and 128 (probably intermediates). 127 is mine, fixes IMO overoptimized case for DirectMapping which unlike its superclass (thus all the other mappings as there is no other specialization), stopped converting primary keys to db value in fk->pk relationships.
On 11-10-17 21:50, Herby VojÄÃk wrote:
129 is from different author, who skipped upload of its 127 and 128 (probably intermediates).
127 is mine, fixes IMO overoptimized case for DirectMapping which unlike its superclass (thus all the other mappings as there is no other specialization), stopped converting primary keys to db value in fk->pk relationships.
Name: ConfigurationOfGlorp-StephanEggermont.62 Author: StephanEggermont Time: 11 October 2017, 10:00:05.488994 pm UUID: a7105b9b-ac17-0d00-a62f-44e602acb0bc Ancestors: ConfigurationOfGlorp-StephanEggermont.61 Patch for stable/release2/2.0.1 Fix error with DirectMapping primary key not being converted to db type. In the metarepos, dbxtalk/glorp and dbxtalk/configurations
stephan wrote:
On 11-10-17 21:50, Herby VojÄÃk wrote:
129 is from different author, who skipped upload of its 127 and 128 (probably intermediates).
127 is mine, fixes IMO overoptimized case for DirectMapping which unlike its superclass (thus all the other mappings as there is no other specialization), stopped converting primary keys to db value in fk->pk relationships.
Name: ConfigurationOfGlorp-StephanEggermont.62 Author: StephanEggermont Time: 11 October 2017, 10:00:05.488994 pm UUID: a7105b9b-ac17-0d00-a62f-44e602acb0bc Ancestors: ConfigurationOfGlorp-StephanEggermont.61
Patch for stable/release2/2.0.1
Fix error with DirectMapping primary key not being converted to db type.
In the metarepos, dbxtalk/glorp and dbxtalk/configurations
Thank you very much, sir. :-)
On Wed, Oct 11, 2017 at 09:50:46PM +0200, Herby Voj????k wrote:
stephan wrote:
On 11-10-17 20:33, Herby Voj????k wrote:
127 is general, is not sqlite-specific. Fixes any case where primary key is not primitive and has converter.
Should 127 and 129 be merged first, and should current development be promoted to release? And why is 128 missing?
Stephan
129 is from different author, who skipped upload of its 127 and 128 (probably intermediates).
127 is mine, fixes IMO overoptimized case for DirectMapping which unlike its superclass (thus all the other mappings as there is no other specialization), stopped converting primary keys to db value in fk->pk relationships.
129 is mine. 129 is dated July 2016 while 127 is dated August 2017, which I guess accounts for why I based 129 on 126. On Wed, Oct 11, 2017 at 11:31:17AM +0200, stephan wrote:
On 06-10-17 17:22, Herby Voj????k wrote:
Any chance of incorporating fixes 127 / 129?
Sure, as soon as someone tells me they are safe to add. I am just testing Glorp with P3 and Postgres now, and don't have the capacity to verify these changes other than by just reading the delta.
Stephan
129 has been available since July 2016 and was promoted to #development by Pierce in January 2017. I've been using it without any problems since I submitted it in July 2016. Cheers, Alistair
participants (5)
-
Alistair Grant -
Herby VojÄÃk -
stephan -
Stephane Ducasse -
Sven Van Caekenberghe