quote "don't give advice unless asked" it is not you! i think most of the people feel the same way. at least i do i suspect that in your case a review is mandatory as well as fixing its comments. from my perspective a…
> 2) languages such as PL/SQL are much poorer than any modern programming language true but it is for a reason. For example you can replace/upgrade any piece of code on the running system transactionally. But in a…
many say that git has an intuitive/concise data model. But it seems that even git team itself has not quite got it. Looking at one of the latest changes [1] in which a _new_ merge strategy (ort) was introduced and made…
have been wondering for a while why HFTs exist when exchanges have holidays and trading hours [1]? doesn't the sub-milisecond speed contradict to the several hours pause in trading? wouldn't be possible to impose some…
Erlang
before the change CREATE TABLE the_table (was_char CHAR); CREATE VIEW table_read_api AS SELECT was_char FROM the_table; a client consumes data via: select was_char from table_read_api; after the change alter table…
a view would allow you to change a field's type. something like this CREATE VIEW table_read_api AS SELECT TO_CHAR(now_int) as was_char FROM the_table; not sure that the view is an internal structure because it will be…
what if we put the table behind a view? would it be count as a communication via API?
> which is going on the opposite direction as you would expect. It looks like a bug which should be fixed. Git should create a merge commit when it sees that "the direction" changes.
quote "don't give advice unless asked" it is not you! i think most of the people feel the same way. at least i do i suspect that in your case a review is mandatory as well as fixing its comments. from my perspective a…
> 2) languages such as PL/SQL are much poorer than any modern programming language true but it is for a reason. For example you can replace/upgrade any piece of code on the running system transactionally. But in a…
many say that git has an intuitive/concise data model. But it seems that even git team itself has not quite got it. Looking at one of the latest changes [1] in which a _new_ merge strategy (ort) was introduced and made…
have been wondering for a while why HFTs exist when exchanges have holidays and trading hours [1]? doesn't the sub-milisecond speed contradict to the several hours pause in trading? wouldn't be possible to impose some…
Erlang
before the change CREATE TABLE the_table (was_char CHAR); CREATE VIEW table_read_api AS SELECT was_char FROM the_table; a client consumes data via: select was_char from table_read_api; after the change alter table…
a view would allow you to change a field's type. something like this CREATE VIEW table_read_api AS SELECT TO_CHAR(now_int) as was_char FROM the_table; not sure that the view is an internal structure because it will be…
what if we put the table behind a view? would it be count as a communication via API?
> which is going on the opposite direction as you would expect. It looks like a bug which should be fixed. Git should create a merge commit when it sees that "the direction" changes.