2016-11-23 2:26 GMT+03:00 Leyne, Sean :
> I can't imagine how the engine could manage to keep the schema/object cache
> and transaction context in sync or, in the absence of that, to 'broadcast'
> that schema has changed and any existing cached object should be released as
> soon as possible, to
On 23/11/2016 06:15, Roman Simakov wrote:
> 2016-11-23 2:26 GMT+03:00 Leyne, Sean :
>> I can't imagine how the engine could manage to keep the schema/object cache
>> and transaction context in sync or, in the absence of that, to 'broadcast'
>> that schema has changed and any existing cached objec
Em 23/11/2016 08:10, Adriano dos Santos Fernandes escreveu:
> On 23/11/2016 06:15, Roman Simakov wrote:
>> 2016-11-23 2:26 GMT+03:00 Leyne, Sean :
>>> I can't imagine how the engine could manage to keep the schema/object cache
>>> and transaction context in sync or, in the absence of that, to 'bro
> On Nov 22, 2016, at 7:26 PM, Leyne, Sean wrote:
>
>
>> SQL>
>> SQL> select * from v;
>>
>> A
>> ==
>> Statement failed, SQLSTATE = 22001
>> arithmetic exception, numeric overflow, or string truncation -string right
>> truncation
>> SQL>
>>
>>
>> As you can see.. there is no error unti
On 23/11/2016 10:56, Alexandre Benson Smith wrote:
> create view v as select a from t;
When you use the base field directly, the view field uses the same domain.
When you create an expression based on this field, the change to it does
not reflect in the view.
Because Firebird does not recompile
Em 23/11/2016 11:08, Adriano dos Santos Fernandes escreveu:
> On 23/11/2016 10:56, Alexandre Benson Smith wrote:
>> create view v as select a from t;
> When you use the base field directly, the view field uses the same domain.
>
> When you create an expression based on this field, the change to it
Dne 23. 11. 2016 v 14:08 Adriano dos Santos Fernandes napsal(a):
> On 23/11/2016 10:56, Alexandre Benson Smith wrote:
>> create view v as select a from t;
> When you use the base field directly, the view field uses the same domain.
>
> When you create an expression based on this field, the change t
On 23/11/2016 11:18, Alexandre Benson Smith wrote:
> Wich leads FB to allow a change on a field and the developer would not
> know it will cause an error in production months later.
>
> I think it should prevent the change until all dependent objects are
> droped (annoying) or recompile the depen
Em 23/11/2016 11:37, Adriano dos Santos Fernandes escreveu:
>
> And in my opinion problem of metadata changes and
> unreliable/unpredictable behavior with concurrent sessions precedes this
> one, otherwise deeper recompilation will be a big problem.
Perhaps I missed your point.
The case I provide
On 23/11/2016 11:35, Ivan Přenosil wrote:
> Another example - when the table field uses user defined domain, the
> same domain will be used by view.
> When I alter the table field by changing it to use another wider domain,
> the view will retain the original narrow domain.
>
Yes.
Another approa
On 23/11/2016 11:50, Alexandre Benson Smith wrote:
> Em 23/11/2016 11:37, Adriano dos Santos Fernandes escreveu:
>> And in my opinion problem of metadata changes and
>> unreliable/unpredictable behavior with concurrent sessions precedes this
>> one, otherwise deeper recompilation will be a big prob
23.11.2016 14:54, Adriano dos Santos Fernandes wrote:
> But that (DDL changes with concurrent sessions) is unreliable.
>
> And if you change a single view that recompiles 100 views, you multiple
> the unreliability by 100 in the production environment.
That's why I, personally, prefer to prohib
On 23/11/2016 12:37, Dimitry Sibiryakov wrote:
> 23.11.2016 14:54, Adriano dos Santos Fernandes wrote:
>> But that (DDL changes with concurrent sessions) is unreliable.
>>
>> And if you change a single view that recompiles 100 views, you multiple
>> the unreliability by 100 in the production enviro
Em 23/11/2016 12:37, Dimitry Sibiryakov escreveu:
> 23.11.2016 14:54, Adriano dos Santos Fernandes wrote:
>> But that (DDL changes with concurrent sessions) is unreliable.
>>
>> And if you change a single view that recompiles 100 views, you multiple
>> the unreliability by 100 in the production env
Em 23/11/2016 11:54, Adriano dos Santos Fernandes escreveu:
> On 23/11/2016 11:50, Alexandre Benson Smith wrote:
>> Em 23/11/2016 11:37, Adriano dos Santos Fernandes escreveu:
>>> And in my opinion problem of metadata changes and
>>> unreliable/unpredictable behavior with concurrent sessions preced
Lionel Elie Mamane committed a patch related to this issue tdf#101789
Firebird 3 - fails to build on OSX 10.11.x with clang.
It has been pushed to libreoffice "master": tdf#101789 work around
DYLD_LIBRARY_PATH limitations on newer MacOS X.
https://bugs.documentfoundation.org/show_bug.cgi?id=10178
16 matches
Mail list logo
