18.01.2017 12:38, Alex Peshkoff wrote:
>
> Currently with dfw we do have a lot of DDL errors raised at commit time
> i.e. it's not a regression.
True, but only because the actual work is performed during commit. If we
claim that DDL changes are applied immediately, but error is thrown at
18.01.2017 11:09, Dmitry Yemanov wrote:
> I would seriously question the need to allow concurrent DDL against the
> same objects. This is simply not the way people work with the relational
> databases. I'd rather lock the metadata being changed at the DDL time
> and until commit.
+1
--
On 01/18/17 01:15, Leyne, Sean wrote:
> Roman,
>
>> May I ask an example?
>>
>> Will it work?
>>
>> start transaction;
>>
>> alter table T add column N INTEGER;
>>
>> insert into T (..., N) values (..., 10);
>>
>> commit;
> IMO, it should.
>
> But, the interesting question would be:
>
> What would
Could you try with the latest version from ppa ?
https://launchpad.net/~mapopa/+archive/ubuntu/ppa
On Tue, Jan 17, 2017 at 7:46 PM, Denys Khanzhyiev wrote:
> Hi all,
> trying to setup a kind of CI with travis for node-firebird-libfbclient.
> Keep getting SEG FAULT when
18.01.2017 10:53, Alex Peshkoff wrote:
> Statements prepared in a transaction performing DDL changes should not
> be usable in context of other transactions. Reverse rule should also be
> true - statement prepared outside particular DDL transaction is not
> usable in it. This will be new
Don't forget about SAVEPOINT handling! It can make things very messy in
this case (BUT expected to work as part of the transaction logic from my
point of view).
Lock should be applied in case of altering, parallel altering should be
not allowed. (same as update a record, instant lock conflict
It works in my Ubuntu VM, travis script needs to set default db password.
2017-01-18 10:38 GMT+01:00 marius adrian popa :
> Could you try with the latest version from ppa ?
>
> https://launchpad.net/~mapopa/+archive/ubuntu/ppa
>
> On Tue, Jan 17, 2017 at 7:46 PM, Denys
On Jan 18, 2017, at 11:17 AM, Gerhard S (JIRA) wrote:
>
> Insert NULL into identity column with auth generated value
> --
>
> Key: CORE-5460
> URL:
Recursive Definition
Key: CORE-5461
URL: http://tracker.firebirdsql.org/browse/CORE-5461
Project: Firebird Core
Issue Type: Bug
Affects Versions: 2.5.5
Environment: Windows Server 2008 R2 64 Bits
Erro Criação Chave Primária
---
Key: CORE-5462
URL: http://tracker.firebirdsql.org/browse/CORE-5462
Project: Firebird Core
Issue Type: Bug
Affects Versions: 2.5.5
Environment: Windows Server 2008 R2 64
Ann, I assigned it to me based on Dimitry S. comment.
After your comment, I edited the case to reflect the standard.
Adriano
Em 18/01/2017 19:51, Ann Harrison escreveu:
> On Jan 18, 2017, at 11:17 AM, Gerhard S (JIRA)
> wrote:
>>
>> Insert NULL into identity column
19.01.2017 00:51, Ann Harrison wrote:
>
> In what universe does that make sense? The field is NOT NULL. You're
> storing NULL in it. That's an error.
I'd say it depends. What about a BEFORE trigger converting input NULL to
something valid before storing?
Dmitry
Hello, All.
When Firebird looks for free id for a new object it does not recognize which
unique
constraint is violated. As the result, following script takes quite much time
before
showing error:
create database "test";
create or alter sequence aaa start with 1000;
set autoddl off;
> > Roman,
> >
> >> May I ask an example?
> >>
> >> Will it work?
> >>
> >> start transaction;
> >>
> >> alter table T add column N INTEGER;
> >>
> >> insert into T (..., N) values (..., 10);
> >>
> >> commit;
> > IMO, it should.
> >
> > But, the interesting question would be:
> >
> > What would
Insert NULL into identity column with auth generated value
--
Key: CORE-5460
URL: http://tracker.firebirdsql.org/browse/CORE-5460
Project: Firebird Core
Issue Type: Improvement
15 matches
Mail list logo