FlameRobin

On Fri, Oct 29, 2010 at 9:27 AM, Kjell Rilbe <kjell.rilbe@...> wrote:
> In ISQL it works and returns a single row, so I assume this is a bug in FR.
> The log page shows this after executing the two queries:
>
> PLAN JOIN (F INDEX (IDX_Företag_Orgnr), HANT INDEX
> (IX_PK_Uppgiftshanterare), UH INDEX (IX_Uppgiftshållare_HanDS2), UPG INDEX
> (IX_Uppgift_Hållare), UPD INDEX (IX_PK_Uppdatering))

What's the query plan in ISQL? If different indexes are used that
could indicate some problem.

-- 
Milan Babuskov
http://www.flamerobin.org

Michael,

> If nobody minds I'd like to show multiple connections of the same
> user as a single entry with the connection count appended: "foo_user
> (42)".
>
> I'd also take the opportunity to remove the "Show connected users"
> command from the database menu.
>
> Any objections?

Not from me.
-- 
Nando Dessena

On Thu, Oct 28, 2010 at 2:17 PM, Michael Hieke <mghie@...> wrote:
> since I'm currently working on a project where multiple program
> instances with multiple connection threads each connect to the same
> database, I find that it's not really very usable to have them all
> appear in the database property page as so many entries under "Connected
> users".
>
> If nobody minds I'd like to show multiple connections of the same user
> as a single entry with the connection count appended: "foo_user (42)".
>
> I'd also take the opportunity to remove the "Show connected users"
> command from the database menu.
>
> Any objections?

No objections, but ideas :D

It might be interested to present a dialog/frame, with 2 panes or 2
tabs in a tabbed control. One would simply display the listctrl with
"foo_user(42)" you already mentioned, while other could query
MON$ATTACHMENTS and provide additional information about connected
users, perhaps in a table or tree control. I believe tree would be
better, we could have one node for each username, and when you open it
(collapse), you would get details for each connection like IP address,
application name and such.

Another idea: the list(s) could be refreshed periodically in a
user-defined interval.

What do you think?

-- 
Milan Babuskov
http://www.flamerobin.org

Milan,

On 28.10.2010 18:12, Milan Babuskov wrote:

> No objections,

good, as you might have seen from the commit message I already went 
ahead and did it ;-)

> It might be interested to present a dialog/frame, with 2 panes or 2
> tabs in a tabbed control. One would simply display the listctrl with
> "foo_user(42)" you already mentioned, while other could query
> MON$ATTACHMENTS and provide additional information about connected
> users, perhaps in a table or tree control. I believe tree would be
> better, we could have one node for each username, and when you open
> it (collapse), you would get details for each connection like IP
> address, application name and such.

I have already thought about it, in the form of a new page in the 
database property page that is visible only for databases with recent 
ODS.  What I have seen so far from Nando's work with the templates makes 
this look fairly easy to implement.

> Another idea: the list(s) could be refreshed periodically in a
> user-defined interval.

A few days ago I added the standard keyboard shortcuts for Refresh 
(Ctrl+R and in addition to that F5 for Windows) and Close Window (Ctrl+W 
and in addition Ctrl+F4 for Windows), so it is already possible to 
manually request an updated page.  I personally have no need for an 
automatic refresh, but IMHO it should be done on the 
MetadataPropertyFrame panel too, it could be useful for other pages like 
generator values, or statistics page of tables.  It could be a command 
in the context menu.

Thanks

-- 
Michael Hieke

Hi,

On 26.10.2010 10:40, Bozzy wrote:

> I've tried the new snapshot build for win32 and encountered a problem
> just when connecting to a DB. The program simply crashes

sorry for that, there seems to be a conflict between the MSVC runtime 
DLL we have always used, and the executables the build tools on my new 
machine are creating.  Some misstep in the installation order probably. 
  I will get things up and running ASAP and post new 32 bit packages, I 
have deleted the original ones from SF.net to keep people from 
downloading and trying them out.

As soon as I have a working build setup I'll post new 32 bit packages, 
the 64 bit packages should work OK.

Thanks for the report, and sorry again

-- 
Michael Hieke

New 32 bit setup and ZIP files have been posted to SF.net.  Sorry again 
for the broken packages.

Thanks

-- 
Michael Hieke

Hi,

On 25.10.2010 17:12, marius adrian popa wrote:

>   export CXX="clang++"
>
> ./src/metadata/collection.h:96:11: error: no matching constructor
> for initialization of 'MetadataCollectionBase'
>          : MetadataCollectionBase(type, database.get(), name),
>            ^                      ~~~~~~~~~~~~~~~~~~~~~~~~~~
> ./src/metadata/collection.h:40:5: note: candidate constructor not
> viable: cannot convert argument of incomplete type 'Database *' to
> 'MetadataItem *'

that one I've been struggling with in the last days already - I guess 
just being able to compile with MSVC and GCC isn't good enough.

There is a real problem here - a Database has lots of metadata item 
collections, which should have a weak link back to the database they 
belong to.  I'm at a loss at the moment on how to fix this.

> ./src/addconstrainthandler.cpp:65:50: error: default initialization of
> an object of const type 'AddConstraintHandler const' requires a
> user-provided default constructor
> const AddConstraintHandler AddConstraintHandler::handlerInstance;

That's probably easier to fix by adding the necessary constructors.  The 
other one is much harder, so I'll start looking into that one first.

If anybody has a good tip, please speak up.

Thanks

-- 
Michael Hieke

Nando,

On 25.10.2010 21:39, I wrote:

>> ./src/addconstrainthandler.cpp:65:50: error: default initialization of
>> an object of const type 'AddConstraintHandler const' requires a
>> user-provided default constructor
>> const AddConstraintHandler AddConstraintHandler::handlerInstance;
>
> That's probably easier to fix by adding the necessary constructors.

it's even easier to fix by removing the const specifier from the private 
static instance.  I don't think that this would be a problem, given that 
it's private.  Do you mind me removing those from all handlers?

As for the other problem - it's actually easy to fix as well, but a bit 
tedious.  Aggressive use of forward declarations instead of header 
inclusion will make things compile.

Thanks

-- 
Michael Hieke

On 25.10.2010 17:12, marius adrian popa wrote:

>   export CXX="clang++"
>                                                   ^
> 2 errors generated.

I have it compiling on my Ubuntu 10.10 VM.  But it doesn't link with the 
system-provided wxWidgets libraries, and building wxWidgets 2.8 SVN 
branch with clang++ fails as well.

I'm leaving it for now, but I'll probably soon commit the header 
inclusion changes because they remove a lot of unnecessary dependencies 
and should therefore decrease rebuild times after changes.

Thanks

-- 
Michael Hieke

On Mon, Oct 25, 2010 at 11:06 AM, Michael Hieke <mghie@...> wrote:
> Hi all,
>
> I have posted SVN revision 2048 (nice round number) snapshot files for
> Windows 32 and 64 bits, both setup and ZIP files.
>
> Enjoy, and please be sure to report any bugs, regressions or suggestions.
>
> Thanks

I have added the news on blog , main site , firebirdnews :)
Let's see the feedback
>
> --
> Michael Hieke
>
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> Flamerobin-devel mailing list
> Flamerobin-devel@...
> https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
>

On Sat, Oct 23, 2010 at 2:43 PM, Michael Hieke <mghie@...> wrote:
>     wxString prefix(getName_().substr(0, 4));
>     if (prefix == wxT("MON$"))
>         return true;
>     if (prefix != wxT("RDB$"))
>         return false;
>     long l;
>     return getName_().Mid(4).ToLong(&l);    // numeric = system
>
> What's the reason for this?  All domains used in system tables (like
> RDB$SYSTEM_FLAG) are surely system domains, so why should
> Domain::isSystem() return false for them?

One more place where you'll need to make a distinction between
"automatic" and "system" domain. From thread "Renamed: Extract domains
for system table columns" at that day between Dalton Calford and me on
this list:

Dalton Calford wrote:
>> When looking at System tables, the metadata
>> extract pulls out the raw data types instead of the system domains
>
> Yes, it seems like we have a check if domain starts with RDB$ and
> decide it's automatic domain. System tables' columns actually have
> domains like RDB$VALUE, RDB$FIELD_NAME, etc. so it does start with
> RDB$, but we have to treat it as "explicitly defined domain".
>
> I just committed a fix for this (domain.cpp/h). It seems to work fine.

-- 
Milan Babuskov
http://www.flamerobin.org

Milan,

On 23.10.2010 17:29, Milan Babuskov wrote:

> One more place where you'll need to make a distinction between
> "automatic" and "system" domain. From thread "Renamed: Extract
> domains for system table columns" at that day between Dalton Calford
> and me on this list:
>
> Dalton Calford wrote:
>>> When looking at System tables, the metadata
>>> extract pulls out the raw data types instead of the system domains
>>
>> Yes, it seems like we have a check if domain starts with RDB$ and
>> decide it's automatic domain. System tables' columns actually have
>> domains like RDB$VALUE, RDB$FIELD_NAME, etc. so it does start with
>> RDB$, but we have to treat it as "explicitly defined domain".
>>
>> I just committed a fix for this (domain.cpp/h). It seems to work
>> fine.

I see.  But it's unclear to me how to go from here.  I don't think that 
all the RDB$XXX domains should be nodes in the "Domains" subtree.

And there are so many differences between these three kinds of domains 
(user, system and automatic) that they should probably go into three 
different collections.  Should we finally bite the bullet and create a 
system domain collection class?

As I understand it the system domain collection would be similar to the 
system table collection (optionally shown in the tree) while the 
collection of automatic domains would be an internal one.  Both would be 
SysDomains, right?

Thanks

-- 
Michael Hieke

On Sat, Oct 23, 2010 at 5:57 PM, Michael Hieke <mghie@...> wrote:
> I don't think that
> all the RDB$XXX domains should be nodes in the "Domains" subtree.

I Agree. In fact, I think none of those should be there.

> And there are so many differences between these three kinds of domains
> (user, system and automatic) that they should probably go into three
> different collections.  Should we finally bite the bullet and create a
> system domain collection class?

As long as I'm not biting that bullet by doing the coding, I have
nothing against it. ;)

> As I understand it the system domain collection would be similar to the
> system table collection (optionally shown in the tree) while the
> collection of automatic domains would be an internal one.  Both would be
> SysDomains, right?

I'm not sure. Why would anyone want to see those system domains like
RDB$SYSTEM_FLAG? They are internal, undocumented feature of Firebird
system tables and user's probably should not use them for columns of
user tables anyway because it is not guaranteed to be compatible with
future versions of FB.

Here's MHO how it should work. Definitions:

1. UDD (user defined domain) - explicitly defined using CREATE DOMAIN
2. SD (system domain) - RDB$ domain with a name, not a number after
RDB$, say RDB$SYSTEM_FLAG
3. AD (automatic domain) - assigned for user tables when column is
created without explicit domain RDB$123

- only UDD should be listed in tree and shown in FieldPropertiesDialog
- when both domain and datatype is shown for column in tree or
property page, we should show UDD and SD if available
- when extracting DDL, the priority should be: UDD, SD, datatype string, AD

In this last case AD is shown if datatype is not detected. Shouldn't
ever happen unless system tables are modified directly.

Now, I don't see any of these requires that we have 3 collections. I
see only a need for two, one containing UDDs and other containing SDs
and ADs. Difference between SD and AD is only observed for a
particular domain, never as a collection.

All IMHO, of course.

-- 
Milan Babuskov
http://www.flamerobin.org

Hi Milan,

thanks for the comments.

On 23.10.2010 18:15, Milan Babuskov wrote:

> I Agree. In fact, I think none of those should be there.

OK.

> I'm not sure. Why would anyone want to see those system domains like
> RDB$SYSTEM_FLAG? They are internal, undocumented feature of Firebird
> system tables and user's probably should not use them for columns of
> user tables anyway because it is not guaranteed to be compatible with
> future versions of FB.

I guess you're right, but it won't be a problem to add a system domain 
collection later on if we change our minds on that.  The first step is 
to separate the UDs from the rest.

> 1. UDD (user defined domain) - explicitly defined using CREATE DOMAIN
> 2. SD (system domain) - RDB$ domain with a name, not a number after
> RDB$, say RDB$SYSTEM_FLAG
> 3. AD (automatic domain) - assigned for user tables when column is
> created without explicit domain RDB$123
>
> - only UDD should be listed in tree and shown in FieldPropertiesDialog
> - when both domain and datatype is shown for column in tree or
> property page, we should show UDD and SD if available
> - when extracting DDL, the priority should be: UDD, SD, datatype string, AD
>
> In this last case AD is shown if datatype is not detected. Shouldn't
> ever happen unless system tables are modified directly.
>
> Now, I don't see any of these requires that we have 3 collections. I
> see only a need for two, one containing UDDs and other containing SDs
> and ADs. Difference between SD and AD is only observed for a
> particular domain, never as a collection.

Nice summary, I completely agree with it.  I'll see what I can do.

Thanks

-- 
Michael Hieke

Milan, Michael,

>> 1. UDD (user defined domain) - explicitly defined using CREATE
>> DOMAIN 2. SD (system domain) - RDB$ domain with a name, not a
>> number after RDB$, say RDB$SYSTEM_FLAG 3. AD (automatic domain) -
>> assigned for user tables when column is created without explicit
>> domain RDB$123
>>
>> - only UDD should be listed in tree and shown in
>> FieldPropertiesDialog - when both domain and datatype is shown for
>> column in tree or property page, we should show UDD and SD if
>> available - when extracting DDL, the priority should be: UDD, SD,
>> datatype string, AD
>>
>> In this last case AD is shown if datatype is not detected.
>> Shouldn't ever happen unless system tables are modified directly.
>>
>> Now, I don't see any of these requires that we have 3 collections.
>> I see only a need for two, one containing UDDs and other containing
>> SDs and ADs. Difference between SD and AD is only observed for a
>> particular domain, never as a collection.
>
> Nice summary, I completely agree with it. I'll see what I can do.

I agree as well, but I'd go to the point of saying that ADs are not even
domains at all, and FR shouldn't bother about them when reading
RDB$FIELDS. They aren't needed anyway, except in this case:

>> In this last case AD is shown if datatype is not detected.

I can't imagine how it can ever be.
-- 
Nando Dessena

On Sat, Oct 23, 2010 at 7:51 PM, Nando Dessena <nando@...> wrote:
>>> In this last case AD is shown if datatype is not detected.
>
> I can't imagine how it can ever be.

Some tools (IBExpert, EMS, etc.) allow user to do some changes on
table columns that are otherwise "forbidden" by Firebird (because of
dependencies or lack of DDL command support) by changing the system
tables directly. And we're not just talking simple NULL/NOT NULL
change we also do in FR. Those changes can create unconsistent state
in system tables, that you could never reach executing regular DDL
statements. Those tools are aware of changes they might make, so when
you extract DDL using them, it seems fine. However, they are
closed-source, so we don't know what to expect and how to behave.
Firebird also works fine, because they knew which things are important
to change and which are not. I'm talking about things that I've seen
myself in practice, because I was using IBE Personal Edition for years
until FR got all the features I needed.

Of course, instead of AD, we could alternatively show something like
"UNKNOWN DATATYPE" :)

BTW, another case when AD could be shown is when you do have a domain
like RDB$123, but such domain is not present in RDB$FIELDS. This could
also happen when system tables are modified directly, or when you have
another user working concurrently on the same database and metadata
tree in FR is not up to date.

-- 
Milan Babuskov
http://www.flamerobin.org

Hi all,

I have just committed the change, please test.

On 24.10.2010 13:39, Milan Babuskov wrote:

> BTW, another case when AD could be shown is when you do have a
> domain like RDB$123, but such domain is not present in RDB$FIELDS.
> This could also happen when system tables are modified directly, or
> when you have another user working concurrently on the same database
> and metadata tree in FR is not up to date.

The latter shouldn't be much of a problem, because domains are loaded 
on-demand when they are not found in the collections.

Thanks

-- 
Michael Hieke

On Sun, Oct 24, 2010 at 2:17 PM, Michael Hieke <mghie@...> wrote:
> I have just committed the change, please test.

Seems to work properly.

-- 
Milan Babuskov
http://www.flamerobin.org