Why not just establish a mechanism for other providers to register their
dpb codes. It isn't like their is either a shortage of unused codes or a
large number of new providers. That would also provide an opportunity to
discuss and possibly improve a proposal.
I can't help but think that people a
On 03/21/15 17:46, Adriano dos Santos Fernandes wrote:
> On 21-03-2015 05:52, Dimitry Sibiryakov wrote:
>> 21.03.2015 2:18, Adriano dos Santos Fernandes wrote:
>>> All these constants are mixed in the same number space.
>>>
>>> So we say we support multiple providers, but at the same time we expect
Ah, so you defer architecture to anybody who posts a ticket?
Or are you just trying to evade responsibility for a badly thought out and
rude post?
I wouldn't mind discussing architecture if you weren't so eager to declare
something as "completely wrong" without having even a passing familiarity
w
22.03.2015 16:40, Adriano dos Santos Fernandes wrote:
> I'm not here to point the original designer mistakes... I just want to
> fix Firebird design who is claiming to be "multi-provider".
Errr... Wasn't it you who designed all this plugin/provider crap in current
HEAD?..
--
WBR, SD.
---
22.03.2015 16:29, Adriano dos Santos Fernandes wrote:
> Someone following this or not just registered a ticket:
This "someone" is a known troll.
> http://tracker.firebirdsql.org/browse/CORE-4716
Could you try to answer questions in comment I wrote couple of minutes ago?
> I'm so sorry for
On 22-03-2015 13:01, James Starkey wrote:
> So let me get this straight. Your "everything wrong" with DPBs boils
> down to the absence of a comment in a header? Oh, dear me, that is
> indeed a deep and grevious fault.
>
This is one of the problems. As I point out, and not only me, since
someone
So let me get this straight. Your "everything wrong" with DPBs boils down
to the absence of a comment in a header? Oh, dear me, that is indeed a
deep and grevious fault.
I certainly don't pretend to speak for the rest of the project, but if you
want to add a comment to dpb.h (or whatever), you m
I'm not here to point the original designer mistakes... I just want to
fix Firebird design who is claiming to be "multi-provider".
This may be just a comment in a header file establishing ranges of DPBs
of each layer, even if that is already messy. Currently we don't have,
and this is not safe.
On 22-03-2015 11:23, Jim Starkey wrote:
> Adriano, it perpetually amazes me that somebody with such a keen sense of
> database design doesn't dazzle the world with a brilliant new database rather
> than continuously harping about the design of a 30 year old retread database
> system.
>
>> On Ma
Adriano, it perpetually amazes me that somebody with such a keen sense of
database design doesn't dazzle the world with a brilliant new database rather
than continuously harping about the design of a 30 year old retread database
system.
> On Mar 21, 2015, at 6:46 PM, Adriano dos Santos Fernande
21.03.2015 23:46, Adriano dos Santos Fernandes wrote:
> And if you think in pluggable multi-provider, every connection layer
> must know every constant of every provider and every new versions of
> them. Or let people edit binary strings in files.
Can you provide detailed testcase when it is ne
> Connection parameters should be in text form.
Values (in common case) should contain the information about type (UI2, UI4
, String)
OLEDB, for example, uses VARIANT structure.
Regards,
Dmitry Kovalenko.
--
Dive i
On 21-03-2015 16:00, Jim Starkey wrote:
>
>> On Mar 21, 2015, at 2:35 PM, Kovalenko Dmitry
>> wrote:
>>
>> Look to OLE DB properties.
>>
>> Each property has the unique ID: ..
>
> Bad idea for many reasons:
>
> 1. Not upwards compatible from existing scheme
> 2. Gross overkill
>
;
> Look to OLE DB properties.
>
> Each property has the unique ID: ..
>
> Regards,
> Dmitry Kovalenko
>
> -Original Message-
> From: Adriano dos Santos Fernandes [mailto:adrian...@gmail.com]
> Sent: Saturday, March 21, 2015 4:19 AM
> To: firebird-devel
&g
figure out how to assign private codes should take up a different line of
work.
>
> Regards,
> Dmitry Kovalenko
>
> -Original Message-
> From: Adriano dos Santos Fernandes [mailto:adrian...@gmail.com]
> Sent: Saturday, March 21, 2015 4:19 AM
> To: firebird-d
Look to OLE DB properties.
Each property has the unique ID: ..
Regards,
Dmitry Kovalenko
-Original Message-
From: Adriano dos Santos Fernandes [mailto:adrian...@gmail.com]
Sent: Saturday, March 21, 2015 4:19 AM
To: firebird-devel
Subject: [Firebird-devel] Y-valve and DPBs
Hi!
We have
On 21-03-2015 14:40, James Starkey wrote:
> The classical mechanism is to establish one range for systen define
> codes and another for private extensions.
>
> As has beeb pointed out, any engine or transport can safely ignore
> unrecognized codes. Part if the architecture long before Firebird an
The classical mechanism is to establish one range for systen define codes
and another for private extensions.
As has beeb pointed out, any engine or transport can safely ignore
unrecognized codes. Part if the architecture long before Firebird and
Interbase existed.
For those newbies, the Firebir
21.03.2015 18:19, Adriano dos Santos Fernandes wrote:
> "should" and "is" are completely different words.
But in both cases: DPB is the smallest possible problem. Try to describe it
in full
details to see.
--
WBR, SD.
---
On 21-03-2015 14:11, Dimitry Sibiryakov wrote:
> 21.03.2015 18:04, Adriano dos Santos Fernandes wrote:
>> That is not a problem only if we fool people and ourself that we support
>> plugins, but our "plugins" should all reside in the same source tree.
>
>But that's exactly what you do in versi
21.03.2015 18:04, Adriano dos Santos Fernandes wrote:
> That is not a problem only if we fool people and ourself that we support
> plugins, but our "plugins" should all reside in the same source tree.
But that's exactly what you do in version 3.0.
--
WBR, SD.
-
On 21-03-2015 13:16, Dimitry Sibiryakov wrote:
> 21.03.2015 17:03, Adriano dos Santos Fernandes wrote:
>> That's not architecture. Choose something and pray. You do not know how
>> many DPBs a private provider needs nor how many will be added in
>> Firebird in the future.
>
>Yes, but that's th
21.03.2015 17:03, Adriano dos Santos Fernandes wrote:
> That's not architecture. Choose something and pray. You do not know how
> many DPBs a private provider needs nor how many will be added in
> Firebird in the future.
Yes, but that's the way it goes.
The same DBP can have different meanin
On 21-03-2015 12:10, Dimitry Sibiryakov wrote:
> 21.03.2015 15:46, Adriano dos Santos Fernandes wrote:
>> Say, I now create a private XPTO provider
>
>If you really do that, DPB constants will be your smallest problem, trust
> me.
I may only trust you if you say what are these problems and t
21.03.2015 15:46, Adriano dos Santos Fernandes wrote:
> Say, I now create a private XPTO provider
If you really do that, DPB constants will be your smallest problem, trust
me. All you
need is to choose the number big enough to avoid the clash.
--
WBR, SD.
---
On 21-03-2015 05:52, Dimitry Sibiryakov wrote:
> 21.03.2015 2:18, Adriano dos Santos Fernandes wrote:
>> All these constants are mixed in the same number space.
>>
>> So we say we support multiple providers, but at the same time we expect
>> that all providers has identical FB-engine features?
>>
>
21.03.2015 2:18, Adriano dos Santos Fernandes wrote:
> All these constants are mixed in the same number space.
>
> So we say we support multiple providers, but at the same time we expect
> that all providers has identical FB-engine features?
>
> How do non-FB providers may have they own functionali
Hi!
We have in the set of DPB constants:
- Completely FB-engine features
- Features uses in y-valve
All these constants are mixed in the same number space.
So we say we support multiple providers, but at the same time we expect
that all providers has identical FB-engine features?
How do non-FB
28 matches
Mail list logo
