DatabaseAccessor>>#logString: should not truncate the log output

[jtuchel]

Hi there,

building complex queris with Glorp (I guess with any ORM) can involve quite some trial and error.

This is where the ability of DatabaseAccessor to log a created SQL statement issued to the database can help a lot in unsderstanding what nonsense you are constructing ;-)

A bad habit of Glorp is that it cuts off log entries at 4000 characters. When you join a few tables, these 4000 chaarcters can easily be taken by the list of attributes to select and not show what's really important to understand why your resulting SQL doesn't return what you expect.

So I suggest removing the truncation of the SQL statement in DatabaseAccessor>>#logString: completely. I would assume nobody switches logging of the SQL statements on if they are not eagerly hoping to see the full info....

For now, I just uncommented the truncation and use this code:

logString: aString

| stringToLog |

stringToLog := "!aString size > 4000 ifTrue: [aString copyFrom: 1 to: 4000] ifFalse: ["aString"]".
self logger
cr;
show: stringToLog.
(self logOnly and: [stringToLog notEmpty and: [stringToLog last ~= $;]])
ifTrue: [self logger show: ';']

But I would change the method to not using the temp stringToLog at all. 

Any comments? Is anybody from Cincom reading this and has some idea if this truncation was important for any reason and should remain?

Joachim

[Esteban A. Maringolo]

Hi Joachim,

Maybe the DatabaseAccessor should have a log limit (which is 4000 by default) that can be changed. Something like DatabaseAccessor>>#logLineLimit.

Best regards,

Esteban Maringolo Senior Software Developer  emari...@instantiations.com  @emaringolo  /emaringolo  instantiations.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 glorp-group...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/870186ad-92c3-4b24-b173-278d32a773f5n%40googlegroups.com.

[jtuchel]

Hi Esteban,

yes, that was my thought as well.

But I came to the conclusion that I either want to explicitly log and therefor know the truth, or not log at all.

I don't see much value in a limit here. If my SQL is 12000 Characters long and I want to log, I want to see it all. I can't really think of a situation in which I'd want to log in production, but would be okay if some (maybe the one I really want) statements get truncated in the log.

If we introduce a setting, it should at least be modifiable in the ini, imo ;-))))
For me, logging the SQL is for development (exploring) or analysis of error situations in production. For both scenarios, I don't see much value in truncating the statements. Do you see other scenarios?

Joachim

[Alan Knight]

On database drivers that don't support parameterized queries, which at least used to include postgesql, inserts/updates can be very long.

To view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/e2287c91-6751-4870-86bb-1c28b31227efn%40googlegroups.com.

[jtuchel]

Alan,

Yep, that's exactly why I sometimes need to see the full SQL statement that Glorp sends to the DB. Sometimes, I have to experiment and like to copy/paste the statement into an SQL client to further enhance the statement. And sometimes I just need to see what I might be doing wrong. For this I need the full statement ;-)

Some of my selects also get very long in order to have good performance. And I am only beginning to understand how to optimize SQL Queries...

So are you suggesting there is a reason why you introduced the truncation many years ago? Do you happen to remember what these reasons were? I wonder if that is an optimization that might not be tooo relevant any more. I mean, the long String has to be prodeced and sent to the DB anyways, so we can only be talking about the overhead of logging. I see quite some performance penalty in logging SQL to the Transcript, but when I am looking for an error, it's worth it...

Joachim

[Esteban A. Maringolo]

Joachim,

This is a simple change to implement without modifying existing behavior of other users.

The question now remains... where to create an issue for and where to publish the code that fulfills it.

Regards,

Esteban Maringolo Senior Software Developer  emari...@instantiations.com  @emaringolo  /emaringolo  instantiations.com

To view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/688fb302-6432-4109-9fcc-5a538037770an%40googlegroups.com.

[Alan Knight]

It was a long time ago. But I suspect that was the reason. If you're logging to Transcript it can run off the end easily. And by very large, I mean potentially megabytes. So I like the idea of the configurable limit.

To view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/688fb302-6432-4109-9fcc-5a538037770an%40googlegroups.com.

[jtuchel]

Esteban,

we both ask ourselves the same question: how can we provide feedback or fixes to the maintaines of Glorp when we are not using the dialect on which it is maintained. I've spoken to quite a few people about this in the last few years, but found no answer.

To me it seems like Glorp maintainers only care about users of their own Smalltalk dialects and are not interested in any input from outside their bubble. Not sure whose decision this is, but it seems to be made that way. I know people on the team willing to dsicuss questions and improvements in private.

I see two possible solutions: somebody has to fork Glorp for their platform, maybe several Smalltalk dialects can join forces, or Glorp is simply not a viable solution for anybody outside of the bubble of its maintainers. Anything else hasn't been working well for almost 20 years now, and I see little chance of any movement here if this doesn't change.

TBH: the way things are right now, I cannot recommend Glorp to anybody looking for a future-proof ORM for Smalltalk, unless you use the "right" Smalltalk dialect. I like Glorp a lot, it's really good at what it does, and it is impressive what it can do with such little maintenance and development effort spent on it. It's a wonderfuel piece of engineering. But it's aging and it's more or less unmaintained in large parts of the Smalltalk world. Not a solution to bet your business on.

Only remaning question: what is a viable solution for Smalltalk and RDBs ? Are there any alternatives that are in better shape? I am not aware of any.

Joachim