Smalltalk › Frameworks & Tools › GLORP

Suggestion for improvement in GlorpSession createTables

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

2 messages Options

jtuchel

Suggestion for improvement in GlorpSession createTables

Hi there,

In all versions of Glorp I have access to, there are way too many halts. Take a look at

GlorpSession>>#createTables:

    "Create the tables for our descriptor system. This will fail if the tables already exist. Use recreateTables for that."

   | sequences |

   system platform areSequencesExplicitlyCreated
        ifTrue: [
            sequences := self system allSequencesFor: aCollection.
            sequences do: [:each | accessor createSequence: each ifError: [:ex | self halt]]].
   aCollection do: [:each | accessor createTable: each ifError: [:ex | self halt]].
   aCollection do: [:each | accessor createTableIndexes: each ifError: [:ex | self halt]].
   self platform supportsConstraints
        ifTrue: [
            aCollection
                do: [:each | accessor createTableFKConstraints: each ifError: [:ex | self halt]]]

None of these halts should be in the code for multiple reasons:

first, a halt stops a running image and there is not much you can do.

second: a halt does not provide any helpful information to a developer who is looking for the problem. Especially when a method includes multiple halts, it is almost impossible to find out what could have gone wrong.

third: use of Exceptions would make catching them and providing helpful information much easier.

When I last stumbled over this it was a halt occuring in the schema evolution part of starting ap a new version of a headless server image. It took me quite a while to understand that "my" halt was the first one. Once I had that it was easy to guess I was trying to create an already existing sequence. If something useful had been done in the ifError: block, and be it just a simple [:ex| Error signal: 'Sequence creation failed: ', ex description] instead of a halt, I would probably have saved an hour of guesswork.

If there was a process or platform to exchange ideas like this - be it guthub or whatever, such things could be improved in a matter of a few hours or days. Adding the Code, posting a few comments and maybe a test case, could be fast and effective
But the way things work right now, it takes years or doesn't happen at all, because I have no idea who to talk to and how to push changes upstream and maybe have them reviewed...

Any suggestions?

Joachim

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/e7d49bf5-4c1e-4ece-ab25-1fabcbe0b4bfn%40googlegroups.com.

Tom Robinson

Re: Suggestion for improvement in GlorpSession createTables

I believe that Alan has the right to get complete source code any time he would like. Maybe it's time to ask him it pull a copy and put give it to someone to put on GitHub.

As far as the PUL not working on Catalina, my suggestion would be to install in a VirtualBox Linux VM. That would allow you to pull code from the Public Repo using the guest/guest account.

On 10/29/2020 6:59 AM, jtuchel wrote:

Hi there,

In all versions of Glorp I have access to, there are way too many halts. Take a look at

GlorpSession>>#createTables:

    "Create the tables for our descriptor system. This will fail if the tables already exist. Use recreateTables for that."

   | sequences |

   system platform areSequencesExplicitlyCreated
        ifTrue: [
            sequences := self system allSequencesFor: aCollection.
            sequences do: [:each | accessor createSequence: each ifError: [:ex | self halt]]].
   aCollection do: [:each | accessor createTable: each ifError: [:ex | self halt]].
   aCollection do: [:each | accessor createTableIndexes: each ifError: [:ex | self halt]].
   self platform supportsConstraints
        ifTrue: [
            aCollection
                do: [:each | accessor createTableFKConstraints: each ifError: [:ex | self halt]]]

None of these halts should be in the code for multiple reasons:

first, a halt stops a running image and there is not much you can do.

second: a halt does not provide any helpful information to a developer who is looking for the problem. Especially when a method includes multiple halts, it is almost impossible to find out what could have gone wrong.

third: use of Exceptions would make catching them and providing helpful information much easier.

When I last stumbled over this it was a halt occuring in the schema evolution part of starting ap a new version of a headless server image. It took me quite a while to understand that "my" halt was the first one. Once I had that it was easy to guess I was trying to create an already existing sequence. If something useful had been done in the ifError: block, and be it just a simple [:ex| Error signal: 'Sequence creation failed: ', ex description] instead of a halt, I would probably have saved an hour of guesswork.

If there was a process or platform to exchange ideas like this - be it guthub or whatever, such things could be improved in a matter of a few hours or days. Adding the Code, posting a few comments and maybe a test case, could be fast and effective
But the way things work right now, it takes years or doesn't happen at all, because I have no idea who to talk to and how to push changes upstream and maybe have them reviewed...

Any suggestions?

Joachim

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/e7d49bf5-4c1e-4ece-ab25-1fabcbe0b4bfn%40googlegroups.com.