Hi First of all: for my purposes, the hack works very well, so I personally have no need anymore to "make a point" or something, it's only in the best interest of H2 and its quality.
Yes, it is a problem. Imagine the application issues a drop column command. And it fails. What can the application logic do? Unsafely parse the exception message? Surely not. Try parsing the arbitrarily complex CHECK expression SQL string from the I_S? Absolutely not. Manually handling such a problem every time is no option, either. Manually tinkering around, repeatedly spending hours to research and fix "all those little problems" by hand is no option for efficient professional software development. This requires clean architecture, layers, libraries that handle such things programmatically, automatically, generically. Developing quality application code is to define/generate structures once (on the logic/control side, not statically on the model/db side) and then have some layer that handles projection, generation, translation, validation, interaction, etc. Another point of view: Do you iterate over arrays/collection with an unbound index and wait for the AIOOBE to terminate the iteration? No of course not, but instead you programmatically determine the correct bound of the iteration index or use an iterator or a function with internal iteration or so. Same applies to structure definitions, to working with DDL. Proper (maintainable etc.) application code doesn't just "wait for the exception", but it gets things right in the first place. To obtain this when working with DDL, it's the DBMS' obligation to provide a means of telling which of its structures are connected as far as it's relevant to the application. Which reason would an I_S have otherwise? And if there already is an I_S, shouldn't it be complete? Additionally, this issue is no big deal for H2. The information is already perfectly available. All that's missing is the information schema "view" to that detail of the database's internals. If you want to safely and easily improve H2, you should have a desire to put the fix for the hole on the roadmap (low, at the end, of course, because it's not that serious and there exists an acceptable workaround meanwhile). If you say you don't care about such holes in your database, I personally am perfectly fine with it either since I have a workaround. It's just a little sad for H2 itself. Thank you for your time :) Regards On Dec 16, 11:06 am, Thomas Mueller <[email protected]> wrote: > Hi, > > > Otherwise, > > programmatically dropping columns becomes a gamble as soon as CHECK > > constraints are involved. :-(. > > Well, either it works or it doesn't (in which case you get an > exception)... Is it really a problem? > > Regards, > Thomas -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
