Lowercase non reserved keywords

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Lowercase non reserved keywords

Sql Sql
In flamerobin (and most of the development IDEs for firebird), the SQL statements are always uppercased. This is very hard to read on large DDL especially stored procedures. The object names should also be lowercase as it's easier to read.

It is better to uppercase SQL reserved words and lowercase everything else (a preference would be nice). I know Firebird stores everything in uppercase and is case-sensitive, maybe Flamerobin can convert it back to upper case when filtering against sys tables to get metadata information etc.




------------------------------------------------------------------------------
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT
space for its ease of implementation, lower cost, and increased
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: Lowercase non reserved keywords

Milan Babuskov-4
On Fri, Sep 9, 2011 at 2:06 AM, Sql Sql <[hidden email]> wrote:
> In flamerobin (and most of the development IDEs for firebird), the SQL
> statements are always uppercased. This is very hard to read on large DDL
> especially stored procedures. The object names should also be lowercase as
> it's easier to read.

I disagree. I find it much easier when object names are upper case and
the rest (like IF, THEN, DECLARE VARIABLE, BEGIN, END, etc.) is
lowercase.

--
Milan Babuskov
http://www.guacosoft.com

------------------------------------------------------------------------------
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT
space for its ease of implementation, lower cost, and increased
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: Lowercase non reserved keywords

Lester Caine
Milan Babuskov wrote:
>> In flamerobin (and most of the development IDEs for firebird), the SQL
>> >  statements are always uppercased. This is very hard to read on large DDL
>> >  especially stored procedures. The object names should also be lowercase as
>> >  it's easier to read.
> I disagree. I find it much easier when object names are upper case and
> the rest (like IF, THEN, DECLARE VARIABLE, BEGIN, END, etc.) is
> lowercase.

All my code needs rewriting then ;)
At the end of the day, the SQL standard upper cases everything that is not
wrapped in double quotes. Please can we just follow the standard? MySQL's habbit
of returning lower case is a nightmare when trying to work cross database!

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

------------------------------------------------------------------------------
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT
space for its ease of implementation, lower cost, and increased
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: Lowercase non reserved keywords

marius adrian popa
Administrator
In reply to this post by Milan Babuskov-4
On Fri, Sep 9, 2011 at 11:46 AM, Milan Babuskov
<[hidden email]> wrote:
> On Fri, Sep 9, 2011 at 2:06 AM, Sql Sql <[hidden email]> wrote:
>> In flamerobin (and most of the development IDEs for firebird), the SQL
>> statements are always uppercased. This is very hard to read on large DDL
>> especially stored procedures. The object names should also be lowercase as
>> it's easier to read.
>
> I disagree. I find it much easier when object names are upper case and
> the rest (like IF, THEN, DECLARE VARIABLE, BEGIN, END, etc.) is
> lowercase.
Well i like the pascal camelcase
for identifiers and for sql statements lowercase
it's easier to read than screaming caps at me
http://en.wikipedia.org/wiki/CamelCase#Current_usage_in_computing

------------------------------------------------------------------------------
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT
space for its ease of implementation, lower cost, and increased
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: Lowercase non reserved keywords

Nando Dessena
In reply to this post by Sql Sql
FlameRobin is returning what Firebird returns. FlameRobin can format the
keywords (and there IS an option to do so, although it's currently
limited to UPPER/lower but one day we might add Camel) but not the
names. If one wants lowercase names then the Firebird way to do it is to
use quoted identifiers (although I wouldn't bring in the disadvantages
of quoted identifiers just to have them lowercase). It would mean a lot
of hassle in FR code to format names, IMHO.

> In flamerobin (and most of the development IDEs for firebird), the
> SQL statements are always uppercased.

As said above, not true. You can set the case for kaywords (although it
doesn't help you).

Ciao
--
Nando Dessena


------------------------------------------------------------------------------
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT
space for its ease of implementation, lower cost, and increased
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: Lowercase non reserved keywords

Milan Babuskov-4
In reply to this post by Sql Sql
On Fri, Sep 9, 2011 at 2:06 AM, Sql Sql <[hidden email]> wrote:
> This is very hard to read on large DDL
> especially stored procedures.

Stored procedure text is stored in Firebird database, FlameRobin
display's it "as it is". If you create a stored procedure using
lowercase letters and later look at its DDL in FlameRobin, the body of
stored procedure would be the same as you entered it.

If this still bothers you, I can suggest to edit the stored procedure
in FlameRobin's SQL editor and use Ctrl+a, Ctrl+u to lowercase
everything. And then execute that ALTER script.

Regards,

--
Milan Babuskov
http://www.guacosoft.com

------------------------------------------------------------------------------
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT
space for its ease of implementation, lower cost, and increased
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: Lowercase non reserved keywords

Sql Sql
In reply to this post by Nando Dessena
http://en.wikipedia.org/wiki/Bouma
http://www.microsoft.com/typography/ctfonts/wordrecognition.aspx
http://books.google.com/books?id=a9jtyioHfp8C&pg=PA37&lpg=PA37&dq=celko+river&source=bl&ots=PyYtSRC7Xi&sig=8M3TKRs9G6CKV72QTVhvamdM_u4&hl=en&ei=JhZqTvacMIbJgQeS3rjtBQ&sa=X&oi=book_result&ct=result&resnum=6&ved=0CDUQ6AEwBQ#v=onepage&q&f=false   (not sure if you can see the specific chapter on casing in google books)

There are several studies that show that uppercasing SQL keywords and lowercasing everything else improves readability and reduces error and increases productivity. When you have large amount of DDL to debug, it really does make a difference. When you uppercase everything, it's hard to actually see the tables in complex joins or even a particular column in a long list of columns etc.

This is just a guess. Can't you format the DDL when it is written out to the query editor window? Then, when the user runs the query, Flamerobin just runs a UPPER() on the whole query. You are just formatting the "display in the UI" only...not the actual code etc. When the list of tables is being written to the "table objects tree", just run a lowercase() statement. When the user queries it, run a upper() etc. It sounds simple (again, this is just a guess...i don't know how extensive it would be in flamerobin). A preference would satisfy everybody.


From: Nando Dessena <[hidden email]>
To: Development list <[hidden email]>
Sent: Friday, September 9, 2011 7:04 AM
Subject: Re: [Flamerobin-devel] Lowercase non reserved keywords

FlameRobin is returning what Firebird returns. FlameRobin can format the
keywords (and there IS an option to do so, although it's currently
limited to UPPER/lower but one day we might add Camel) but not the
names. If one wants lowercase names then the Firebird way to do it is to
use quoted identifiers (although I wouldn't bring in the disadvantages
of quoted identifiers just to have them lowercase). It would mean a lot
of hassle in FR code to format names, IMHO.

> In flamerobin (and most of the development IDEs for firebird), the
> SQL statements are always uppercased.

As said above, not true. You can set the case for kaywords (although it
doesn't help you).

Ciao
--
Nando Dessena


------------------------------------------------------------------------------
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT
space for its ease of implementation, lower cost, and increased
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel



------------------------------------------------------------------------------
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT
space for its ease of implementation, lower cost, and increased
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: Lowercase non reserved keywords

Michael Hieke
On 09.09.2011 15:40, Sql Sql wrote:

> This is just a guess. Can't you format the DDL when it is written
> out to the query editor window? Then, when the user runs the query,
> Flamerobin just runs a UPPER() on the whole query. You are just
> formatting the "display in the UI" only...not the actual code etc.
> When the list of tables is being written to the "table objects
> tree", just run a lowercase() statement. When the user queries it,
> run a upper() etc. It sounds simple

but it ain't.  You would probably complain (and rightly so) if strings
in your statements would be completely mangled by such naive changing of
letter cases.  It would also eliminate the use of mixed case or non-ANSI
identifiers.
This just can not be done without parsing the statements into expression
trees and rebuilding them afterwards with the proper casing for keywords
and object names applied.

> A preference would satisfy everybody.

Why would a preference be necessary if

> There are several studies that show that uppercasing SQL keywords
> and lowercasing everything else improves readability and reduces
> error and increases productivity.

- let's just force everybody to work at their highest productivity ;-)


But to add my 2 cents to this discussion:

I'm all for a user preference for keyword and object name casing.  OTOH
I'm also for reducing FR code by using the template system.  The latter
however doesn't care what the user preference for keyword cases is.

Add to that the fact that quite often (partial) statements are copied
verbatim from the database to the output text, and the whole thing
becomes very difficult.  I have no idea how to achieve consistent
formatting of statement text in FR.  Short of putting everything through
parsing stages it may even be impossible.

Thanks

--
Michael Hieke

------------------------------------------------------------------------------
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT
space for its ease of implementation, lower cost, and increased
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: Lowercase non reserved keywords

Sql Sql
You're right, you would need to parse the SQL statement into expression trees...however, Flamerobin should already be doing this right? When a query is run, it parses it right? If so, why can't it be parsed and formatted as necessary when displaying some DDL? Should be another extra call to the parseSql method etc which would do the formatting etc. Not sure if a regex can be used instead.


> Add to that the fact that quite often (partial) statements are copied
> verbatim from the database to the output text, and the whole thing
> becomes very difficult. 

But then it becomes data and preserves whatever case it was typed at. If you write a stored procedure to query the sys tables and generate DDL...it is upto you to decide the casing etc.
Ex:
SELECT 'ALTER TABLE ' || TOLOWER(rdb$relation_name) ' ADD COLUMN test VARCHAR(25)' FROM rdb$relations;
The result is data, not SQL as far as Flamerobin should be concerned.




From: Michael Hieke <[hidden email]>
To: [hidden email]
Sent: Friday, September 9, 2011 10:19 AM
Subject: Re: [Flamerobin-devel] Lowercase non reserved keywords

On 09.09.2011 15:40, Sql Sql wrote:

> This is just a guess. Can't you format the DDL when it is written
> out to the query editor window? Then, when the user runs the query,
> Flamerobin just runs a UPPER() on the whole query. You are just
> formatting the "display in the UI" only...not the actual code etc.
> When the list of tables is being written to the "table objects
> tree", just run a lowercase() statement. When the user queries it,
> run a upper() etc. It sounds simple

but it ain't.  You would probably complain (and rightly so) if strings
in your statements would be completely mangled by such naive changing of
letter cases.  It would also eliminate the use of mixed case or non-ANSI
identifiers.
This just can not be done without parsing the statements into expression
trees and rebuilding them afterwards with the proper casing for keywords
and object names applied.

> A preference would satisfy everybody.

Why would a preference be necessary if

> There are several studies that show that uppercasing SQL keywords
> and lowercasing everything else improves readability and reduces
> error and increases productivity.

- let's just force everybody to work at their highest productivity ;-)


But to add my 2 cents to this discussion:

I'm all for a user preference for keyword and object name casing.  OTOH
I'm also for reducing FR code by using the template system.  The latter
however doesn't care what the user preference for keyword cases is.

Add to that the fact that quite often (partial) statements are copied
verbatim from the database to the output text, and the whole thing
becomes very difficult.  I have no idea how to achieve consistent
formatting of statement text in FR.  Short of putting everything through
parsing stages it may even be impossible.

Thanks

--
Michael Hieke

------------------------------------------------------------------------------
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT
space for its ease of implementation, lower cost, and increased
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel



------------------------------------------------------------------------------
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT
space for its ease of implementation, lower cost, and increased
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: Lowercase non reserved keywords

Milan Babuskov-4
In reply to this post by Michael Hieke
On Fri, Sep 9, 2011 at 4:19 PM, Michael Hieke <[hidden email]> wrote:
> Why would a preference be necessary if
>
>> There are several studies that show that uppercasing SQL keywords
>> and lowercasing everything else improves readability and reduces
>> error and increases productivity.
>
> - let's just force everybody to work at their highest productivity ;-)

LOL

Good one, Michael. :)

--
Milan Babuskov
http://www.guacosoft.com

------------------------------------------------------------------------------
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT
space for its ease of implementation, lower cost, and increased
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: Lowercase non reserved keywords

Milan Babuskov-4
In reply to this post by Sql Sql
On Fri, Sep 9, 2011 at 5:52 PM, Sql Sql <[hidden email]> wrote:
> You're right, you would need to parse the SQL statement into expression
> trees...however, Flamerobin should already be doing this right? When a query
> is run, it parses it right?

Only the bare minimum needed. And even if it does not work well, the
worst problem you get currently is that autocomplete feature does not
work.

> If so, why can't it be parsed and formatted as
> necessary when displaying some DDL?

Anything can be done given enough time and effort. We will welcome a
patch if it would do this properly, of course.

And contrary to Michael's joke, I would like to have it optional so I
can turn it off and leave the stuff as it is in the database.

> Should be another extra call to the
> parseSql method etc which would do the formatting etc. Not sure if a regex
> can be used instead.

Regular expressions can only parse "regular languages", SQL is not one
of those. You need a recursive parser to do it right:

http://kore-nordmann.de/blog/do_NOT_parse_using_regexp.html

--
Milan Babuskov
http://www.guacosoft.com

------------------------------------------------------------------------------
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT
space for its ease of implementation, lower cost, and increased
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: Lowercase non reserved keywords

Milan Babuskov-4
In reply to this post by Sql Sql
On Fri, Sep 9, 2011 at 3:40 PM, Sql Sql <[hidden email]> wrote:
> There are several studies that show that uppercasing SQL keywords and
> lowercasing everything else improves readability and reduces error and
> increases productivity.

I fail to see any of the links you've given mention anything about SQL
keywords. It just says that you can learn the "word shape", which in
turn means that if you use consistent scheme (whatever it is) it will
increase your productivity.

> When you have large amount of DDL to debug, it
> really does make a difference.

You shouldn't have created uppercase DDL in the first place if you did
not want it. If you write a stored procedure body as lowercase, it
will remain lowercase in FlameRobin. Just fix your code. It's very
simple: when you open the problematic statement in editor just press
Ctrl+a, Ctrl+u. That's all.

> When you uppercase everything, it's hard to
> actually see the tables in complex joins

FlameRobin does not generate statements with complex joins, users do.
Most of the SQL generated by FlameRobin is either simple or extracted
from database as it is stored.

--
Milan Babuskov
http://www.guacosoft.com

------------------------------------------------------------------------------
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT
space for its ease of implementation, lower cost, and increased
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: Lowercase non reserved keywords

Kjell Rilbe-3
In reply to this post by Sql Sql
Den 2011-09-09 02:06 skrev Sql Sql såhär:

> In flamerobin (and most of the development IDEs for firebird), the SQL
> statements are always uppercased. This is very hard to read on large DDL
> especially stored procedures. The object names should also be lowercase
> as it's easier to read.
>
> It is better to uppercase SQL reserved words and lowercase everything
> else (a preference would be nice). I know Firebird stores everything in
> uppercase and is case-sensitive, maybe Flamerobin can convert it back to
> upper case when filtering against sys tables to get metadata information
> etc.

In my personal experience, I find my SQL to be most readable when I use
lowercase keywords and camelcase quoted names.

Syntax highlighting in the SQL editor helps a lot and is clearer with
quoted names (blue) than unquoted ones (black).

Try it.

Furthermore, proper formatting of the code (meaning line breaks,
indents, etc.) probably does more than ANY casing rule can achieve for
readability.

Kjell
--
--------------------------------------
Kjell Rilbe
DataDIA AB
E-post: [hidden email]
Telefon: 08-761 06 55
Mobil: 0733-44 24 64


------------------------------------------------------------------------------
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT
space for its ease of implementation, lower cost, and increased
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: Lowercase non reserved keywords

Andre van Zuydam
In reply to this post by Milan Babuskov-4
My five cents on this is that in PHP the firebird return variables are uppercase, this makes it simple to convert flamerobin SQL statements to PHP code.

On Fri, Sep 9, 2011 at 10:46 AM, Milan Babuskov <[hidden email]> wrote:
On Fri, Sep 9, 2011 at 2:06 AM, Sql Sql <[hidden email]> wrote:
> In flamerobin (and most of the development IDEs for firebird), the SQL
> statements are always uppercased. This is very hard to read on large DDL
> especially stored procedures. The object names should also be lowercase as
> it's easier to read.

I disagree. I find it much easier when object names are upper case and
the rest (like IF, THEN, DECLARE VARIABLE, BEGIN, END, etc.) is
lowercase.

--
Milan Babuskov
http://www.guacosoft.com

------------------------------------------------------------------------------
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT
space for its ease of implementation, lower cost, and increased
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel



--
Andre van Zuydam
Spiceware Software (Pty) Ltd

=============================
Email:  [hidden email]
Tel:    +27 83 646 4535
Fax:   +27 86 682 6944
Web:    www.spiceware.co.za
=============================

------------------------------------------------------------------------------
Doing More with Less: The Next Generation Virtual Desktop
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops?   How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

unique constraint order bug

Sql Sql
In reply to this post by Kjell Rilbe-3
When I use the flamerobin GUI to add unique constraint on 2 or more columns....it uses the column order in the table instead of the order I check in the checkboxes. This is a problem because I'm hoping to use the unique constraint as an index as well. I would have to manually add the unique constraint without using the GUI as a workaround.

Maybe better to have 2 list boxes where you can add/remove columns into the unique constraint or even some dialog to reorder the columns in the unique constraint.

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: unique constraint order bug

Milan Babuskov-4
On Wed, Sep 21, 2011 at 1:24 AM, Sql Sql <[hidden email]> wrote:
> When I use the flamerobin GUI to add unique constraint on 2 or more
> columns....it uses the column order in the table instead of the order I
> check in the checkboxes. This is a problem because I'm hoping to use the
> unique constraint as an index as well. I would have to manually add the
> unique constraint without using the GUI as a workaround.

Yes, the same should be done for indexes and composite foreign/primary
keys as well.

--
Milan Babuskov
http://www.guacosoft.com

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: unique constraint order bug

Milan Babuskov-4
In reply to this post by Sql Sql
On Wed, Sep 21, 2011 at 1:24 AM, Sql Sql <[hidden email]> wrote:
> When I use the flamerobin GUI to add unique constraint on 2 or more
> columns....it uses the column order in the table instead of the order I
> check in the checkboxes. This is a problem because I'm hoping to use the
> unique constraint as an index as well. I would have to manually add the
> unique constraint without using the GUI as a workaround.
>
> Maybe better to have 2 list boxes where you can add/remove columns into the
> unique constraint or even some dialog to reorder the columns in the unique
> constraint.

I wonder if we could somehow reuse the column-reordering dialog for
this. Any ideas?

--
Milan Babuskov
http://www.guacosoft.com

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel