Home » Eclipse Projects » DTP » catalogs vs. schemas
| catalogs vs. schemas [message #49317] |
Tue, 26 August 2008 15:34  |
Eclipse User |
|
|
|
Originally posted by: first.last.oracle.com
Is there any documentation that explains clearly how and when the methods
Database.getSchemas() and Database.getCatalogs() should be used? Are they
both relevant for all databases (vendors?)? When do you use one and not
the other? etc.
Thanks.
Brian
|
|
| |
| Re: catalogs vs. schemas [message #49467 is a reply to message #49348] |
Sat, 30 August 2008 02:33  |
| Eclipse User |
|
|
|
Originally posted by: first.last.oracle.com
Thanks for the response, Fitz. Let me see if I understand:
Database.getCatalogs() returns a set of catalogs corresponding to
the names returned by java.sql.DatabaseMetaData.getCatalogs().
Depending on the vendor, this may be empty.
Database.getSchemas() returns a set of schemas corresponding to the
schema names returned by java.sql.DatabaseMetaData.getSchemas() whose
catalog names are null. If every schema has a catalog, this will be
empty.
The schemas that do not have a catalog are returned by both
Database.getSchemas() and Catalog.getSchemas(), where the catalog is
some "default" catalog? Is there standard name for the "default" catalog?
And how do I know when a catalog is a "default" and when it actually
corresponds to a catalog name returned by the JDBC driver?
Thanks, again.
Brian
Brian Fitzpatrick wrote:
> Unfortunately, the getCatalogs() vs. getSchemas() calls all boil down to how
> the JDBC driver itself provides that information.
>
> There should always be a default catalog, even if the Database/JDBC driver
> doesn't provide one, so you should (famous last words) always be able to
> drill down from the catalogs level into schemas, tables, etc...
>
> --Fitz
>
> "Brian Vosburgh" <first.last@oracle.com> wrote in message
> news:g91lsh$900$1@build.eclipse.org...
>> Is there any documentation that explains clearly how and when the methods
>> Database.getSchemas() and Database.getCatalogs() should be used? Are they
>> both relevant for all databases (vendors?)? When do you use one and not
>> the other? etc.
>>
>> Thanks.
>> Brian
>
>
|
|
| |
| Re: catalogs vs. schemas [message #49889 is a reply to message #49589] |
Wed, 17 September 2008 00:50 |
| Eclipse User |
|
|
|
Originally posted by: first.last.oracle.com
I have finally gotten around to playing with this stuff....
I am working on the Dali code that determines the "default" catalog
and/or schema for a database connection. We use this information to
validate the user's mappings. For example, if the Employee class/entity
is mapped to the EMP table:
@Entity
@Table(EMP)
public class Employee {...}
we would like to verify, using the DTP Database API, whether the table
exists. This means we need to determine what schema (and, possibly, catalog)
would contain the specified table by default. We would also like to
determine whether a particular database "supports" catalogs, so we
can possibly enable/disable various UI components.
I have tested the Database API on the following databases:
Derby 10.1
MySQL 5.0
Oracle 10g
PostgreSQL 8.2
Sybase ASE 15
Slightly contrary to what you have described, Derby, Oracle, and PostgreSQL
exhibit the following:
Database.getSchemas() returns an empty collection
Database.getCatalogs() returns a single catalog with an empty string
for a name; this catalog contains all the schemas
Sybase:
Database.getSchemas() returns an empty collection
Database.getCatalogs() returns a collection of catalogs corresponding to
the databases on the server, each containing at least a single schema "dbo"
(some also containing a "guest" schema etc.)
MySQL:
Database.getSchemas() returns a single schema with the same name as the
database itself
Database.getCatalogs() returns an empty collection
Assuming that the "default" catalog is similar to what you described (i.e.
the database has a single catalog with an empty string for a name), all of
the databases I have tested, with the exception of MySQL, seem to behave
as one might expect. MySQL's behavior seems completely inconsistent with
the other databases.... Is this a bug or expected behavior?
Unfortunately, Database.getSchemas() does not perform at all like you
described. Is this a bug or expected behavior? Also, is this behavior a
documented part of the API that Dali can rely on in the future? (Note
that the behavior of the PostgreSQL classes seems to have changed
recently....)
Thanks for your help.
Brian
Larry Dunnell wrote:
> You can write all your code without ever using the getSchemas() call.
> The Database.getSchemas() method was added to ease porting for adopters
> moving from WTP. It is really just a shortcut for getting all the
> schemas in all the catalogs. In the case of databases that don't
> support Catalog then it is simply getting all the schemas in the default
> Catalog. A default Catalog can be identified by checking the quantity
> of Catalogs (should be 1 for the default Catalog) and that the name of
> the Catalog is null.
>
>
>
|
|
|
| Re: catalogs vs. schemas [message #50075 is a reply to message #49889] |
Wed, 24 September 2008 15:38 |
| Eclipse User |
|
|
|
Originally posted by: first.last.oracle.com
Anyone?
I know the post is long; but it's pretty straightforward.
Also, it appears that *someone* is working in this area; because
I just moved from 1.6.0 to 1.6.1RC3 and the "catalogs" returned by
Database.getCatalogs() for Sybase is *different*. Arrrgh! It used
to return a "catalog" for each database on the server; but now it
returns only a single "catalog". What is going on? What is
*supposed* to be going on? And how am I supposed to know?
Thanks.
Brian
Brian Vosburgh wrote:
> I have finally gotten around to playing with this stuff....
>
> I am working on the Dali code that determines the "default" catalog
> and/or schema for a database connection. We use this information to
> validate the user's mappings. For example, if the Employee class/entity
> is mapped to the EMP table:
>
> @Entity
> @Table(EMP)
> public class Employee {...}
>
> we would like to verify, using the DTP Database API, whether the table
> exists. This means we need to determine what schema (and, possibly,
> catalog)
> would contain the specified table by default. We would also like to
> determine whether a particular database "supports" catalogs, so we
> can possibly enable/disable various UI components.
>
> I have tested the Database API on the following databases:
>
> Derby 10.1
> MySQL 5.0
> Oracle 10g
> PostgreSQL 8.2
> Sybase ASE 15
>
> Slightly contrary to what you have described, Derby, Oracle, and PostgreSQL
> exhibit the following:
>
> Database.getSchemas() returns an empty collection
> Database.getCatalogs() returns a single catalog with an empty string
> for a name; this catalog contains all the schemas
>
> Sybase:
>
> Database.getSchemas() returns an empty collection
> Database.getCatalogs() returns a collection of catalogs
> corresponding to
> the databases on the server, each containing at least a single
> schema "dbo"
> (some also containing a "guest" schema etc.)
>
> MySQL:
>
> Database.getSchemas() returns a single schema with the same name as the
> database itself
> Database.getCatalogs() returns an empty collection
>
> Assuming that the "default" catalog is similar to what you described (i.e.
> the database has a single catalog with an empty string for a name), all of
> the databases I have tested, with the exception of MySQL, seem to behave
> as one might expect. MySQL's behavior seems completely inconsistent with
> the other databases.... Is this a bug or expected behavior?
>
> Unfortunately, Database.getSchemas() does not perform at all like you
> described. Is this a bug or expected behavior? Also, is this behavior a
> documented part of the API that Dali can rely on in the future? (Note
> that the behavior of the PostgreSQL classes seems to have changed
> recently....)
>
> Thanks for your help.
> Brian
>
>
>
> Larry Dunnell wrote:
>> You can write all your code without ever using the getSchemas() call.
>> The Database.getSchemas() method was added to ease porting for
>> adopters moving from WTP. It is really just a shortcut for getting
>> all the schemas in all the catalogs. In the case of databases that
>> don't support Catalog then it is simply getting all the schemas in the
>> default Catalog. A default Catalog can be identified by checking the
>> quantity of Catalogs (should be 1 for the default Catalog) and that
>> the name of the Catalog is null.
>>
>>
>>
|
|
|
| Re: catalogs vs. schemas [message #50103 is a reply to message #50075] |
Thu, 25 September 2008 10:03 |
| Eclipse User |
|
|
|
Originally posted by: brianf.sybase.com
Nothing should have changed with the Sybase database support from 1.6 to
1.6.1, so that's confusing...
Are you talking ASE or ASA? There's a difference. ASE has the potential of
returning one or more catalogs. ASA doesn't.
And I'll see if I can get some more clarification for you.
--Fitz
"Brian Vosburgh" <first.last@oracle.com> wrote in message
news:gbe4ve$7vo$1@build.eclipse.org...
> Anyone?
>
> I know the post is long; but it's pretty straightforward.
>
> Also, it appears that *someone* is working in this area; because
> I just moved from 1.6.0 to 1.6.1RC3 and the "catalogs" returned by
> Database.getCatalogs() for Sybase is *different*. Arrrgh! It used
> to return a "catalog" for each database on the server; but now it
> returns only a single "catalog". What is going on? What is
> *supposed* to be going on? And how am I supposed to know?
>
> Thanks.
> Brian
>
> Brian Vosburgh wrote:
>> I have finally gotten around to playing with this stuff....
>>
>> I am working on the Dali code that determines the "default" catalog
>> and/or schema for a database connection. We use this information to
>> validate the user's mappings. For example, if the Employee class/entity
>> is mapped to the EMP table:
>>
>> @Entity
>> @Table(EMP)
>> public class Employee {...}
>>
>> we would like to verify, using the DTP Database API, whether the table
>> exists. This means we need to determine what schema (and, possibly,
>> catalog)
>> would contain the specified table by default. We would also like to
>> determine whether a particular database "supports" catalogs, so we
>> can possibly enable/disable various UI components.
>>
>> I have tested the Database API on the following databases:
>>
>> Derby 10.1
>> MySQL 5.0
>> Oracle 10g
>> PostgreSQL 8.2
>> Sybase ASE 15
>>
>> Slightly contrary to what you have described, Derby, Oracle, and
>> PostgreSQL
>> exhibit the following:
>>
>> Database.getSchemas() returns an empty collection
>> Database.getCatalogs() returns a single catalog with an empty string
>> for a name; this catalog contains all the schemas
>>
>> Sybase:
>>
>> Database.getSchemas() returns an empty collection
>> Database.getCatalogs() returns a collection of catalogs corresponding
>> to
>> the databases on the server, each containing at least a single
>> schema "dbo"
>> (some also containing a "guest" schema etc.)
>>
>> MySQL:
>>
>> Database.getSchemas() returns a single schema with the same name as
>> the
>> database itself
>> Database.getCatalogs() returns an empty collection
>>
>> Assuming that the "default" catalog is similar to what you described
>> (i.e.
>> the database has a single catalog with an empty string for a name), all
>> of
>> the databases I have tested, with the exception of MySQL, seem to behave
>> as one might expect. MySQL's behavior seems completely inconsistent with
>> the other databases.... Is this a bug or expected behavior?
>>
>> Unfortunately, Database.getSchemas() does not perform at all like you
>> described. Is this a bug or expected behavior? Also, is this behavior a
>> documented part of the API that Dali can rely on in the future? (Note
>> that the behavior of the PostgreSQL classes seems to have changed
>> recently....)
>>
>> Thanks for your help.
>> Brian
>>
>>
>>
>> Larry Dunnell wrote:
>>> You can write all your code without ever using the getSchemas() call.
>>> The Database.getSchemas() method was added to ease porting for adopters
>>> moving from WTP. It is really just a shortcut for getting all the
>>> schemas in all the catalogs. In the case of databases that don't
>>> support Catalog then it is simply getting all the schemas in the default
>>> Catalog. A default Catalog can be identified by checking the quantity
>>> of Catalogs (should be 1 for the default Catalog) and that the name of
>>> the Catalog is null.
>>>
>>>
>>>
|
|
|
| Re: catalogs vs. schemas [message #50133 is a reply to message #50075] |
Thu, 25 September 2008 10:03 |
| Eclipse User |
|
|
|
Originally posted by: brianf.sybase.com
Nothing should have changed with the Sybase database support from 1.6 to
1.6.1, so that's confusing...
Are you talking ASE or ASA? There's a difference. ASE has the potential of
returning one or more catalogs. ASA doesn't.
And I'll see if I can get some more clarification for you.
--Fitz
"Brian Vosburgh" <first.last@oracle.com> wrote in message
news:gbe4ve$7vo$1@build.eclipse.org...
> Anyone?
>
> I know the post is long; but it's pretty straightforward.
>
> Also, it appears that *someone* is working in this area; because
> I just moved from 1.6.0 to 1.6.1RC3 and the "catalogs" returned by
> Database.getCatalogs() for Sybase is *different*. Arrrgh! It used
> to return a "catalog" for each database on the server; but now it
> returns only a single "catalog". What is going on? What is
> *supposed* to be going on? And how am I supposed to know?
>
> Thanks.
> Brian
>
> Brian Vosburgh wrote:
>> I have finally gotten around to playing with this stuff....
>>
>> I am working on the Dali code that determines the "default" catalog
>> and/or schema for a database connection. We use this information to
>> validate the user's mappings. For example, if the Employee class/entity
>> is mapped to the EMP table:
>>
>> @Entity
>> @Table(EMP)
>> public class Employee {...}
>>
>> we would like to verify, using the DTP Database API, whether the table
>> exists. This means we need to determine what schema (and, possibly,
>> catalog)
>> would contain the specified table by default. We would also like to
>> determine whether a particular database "supports" catalogs, so we
>> can possibly enable/disable various UI components.
>>
>> I have tested the Database API on the following databases:
>>
>> Derby 10.1
>> MySQL 5.0
>> Oracle 10g
>> PostgreSQL 8.2
>> Sybase ASE 15
>>
>> Slightly contrary to what you have described, Derby, Oracle, and
>> PostgreSQL
>> exhibit the following:
>>
>> Database.getSchemas() returns an empty collection
>> Database.getCatalogs() returns a single catalog with an empty string
>> for a name; this catalog contains all the schemas
>>
>> Sybase:
>>
>> Database.getSchemas() returns an empty collection
>> Database.getCatalogs() returns a collection of catalogs corresponding
>> to
>> the databases on the server, each containing at least a single
>> schema "dbo"
>> (some also containing a "guest" schema etc.)
>>
>> MySQL:
>>
>> Database.getSchemas() returns a single schema with the same name as
>> the
>> database itself
>> Database.getCatalogs() returns an empty collection
>>
>> Assuming that the "default" catalog is similar to what you described
>> (i.e.
>> the database has a single catalog with an empty string for a name), all
>> of
>> the databases I have tested, with the exception of MySQL, seem to behave
>> as one might expect. MySQL's behavior seems completely inconsistent with
>> the other databases.... Is this a bug or expected behavior?
>>
>> Unfortunately, Database.getSchemas() does not perform at all like you
>> described. Is this a bug or expected behavior? Also, is this behavior a
>> documented part of the API that Dali can rely on in the future? (Note
>> that the behavior of the PostgreSQL classes seems to have changed
>> recently....)
>>
>> Thanks for your help.
>> Brian
>>
>>
>>
>> Larry Dunnell wrote:
>>> You can write all your code without ever using the getSchemas() call.
>>> The Database.getSchemas() method was added to ease porting for adopters
>>> moving from WTP. It is really just a shortcut for getting all the
>>> schemas in all the catalogs. In the case of databases that don't
>>> support Catalog then it is simply getting all the schemas in the default
>>> Catalog. A default Catalog can be identified by checking the quantity
>>> of Catalogs (should be 1 for the default Catalog) and that the name of
>>> the Catalog is null.
>>>
>>>
>>>
|
|
|
| Re: catalogs vs. schemas [message #50162 is a reply to message #50075] |
Thu, 25 September 2008 10:27 |
| Eclipse User |
|
|
|
Originally posted by: brianf.sybase.com
sorry about the double post, having issues with my newsgroup reader
"Brian Vosburgh" <first.last@oracle.com> wrote in message
news:gbe4ve$7vo$1@build.eclipse.org...
> Anyone?
>
> I know the post is long; but it's pretty straightforward.
>
> Also, it appears that *someone* is working in this area; because
> I just moved from 1.6.0 to 1.6.1RC3 and the "catalogs" returned by
> Database.getCatalogs() for Sybase is *different*. Arrrgh! It used
> to return a "catalog" for each database on the server; but now it
> returns only a single "catalog". What is going on? What is
> *supposed* to be going on? And how am I supposed to know?
>
> Thanks.
> Brian
>
> Brian Vosburgh wrote:
>> I have finally gotten around to playing with this stuff....
>>
>> I am working on the Dali code that determines the "default" catalog
>> and/or schema for a database connection. We use this information to
>> validate the user's mappings. For example, if the Employee class/entity
>> is mapped to the EMP table:
>>
>> @Entity
>> @Table(EMP)
>> public class Employee {...}
>>
>> we would like to verify, using the DTP Database API, whether the table
>> exists. This means we need to determine what schema (and, possibly,
>> catalog)
>> would contain the specified table by default. We would also like to
>> determine whether a particular database "supports" catalogs, so we
>> can possibly enable/disable various UI components.
>>
>> I have tested the Database API on the following databases:
>>
>> Derby 10.1
>> MySQL 5.0
>> Oracle 10g
>> PostgreSQL 8.2
>> Sybase ASE 15
>>
>> Slightly contrary to what you have described, Derby, Oracle, and
>> PostgreSQL
>> exhibit the following:
>>
>> Database.getSchemas() returns an empty collection
>> Database.getCatalogs() returns a single catalog with an empty string
>> for a name; this catalog contains all the schemas
>>
>> Sybase:
>>
>> Database.getSchemas() returns an empty collection
>> Database.getCatalogs() returns a collection of catalogs corresponding
>> to
>> the databases on the server, each containing at least a single
>> schema "dbo"
>> (some also containing a "guest" schema etc.)
>>
>> MySQL:
>>
>> Database.getSchemas() returns a single schema with the same name as
>> the
>> database itself
>> Database.getCatalogs() returns an empty collection
>>
>> Assuming that the "default" catalog is similar to what you described
>> (i.e.
>> the database has a single catalog with an empty string for a name), all
>> of
>> the databases I have tested, with the exception of MySQL, seem to behave
>> as one might expect. MySQL's behavior seems completely inconsistent with
>> the other databases.... Is this a bug or expected behavior?
>>
>> Unfortunately, Database.getSchemas() does not perform at all like you
>> described. Is this a bug or expected behavior? Also, is this behavior a
>> documented part of the API that Dali can rely on in the future? (Note
>> that the behavior of the PostgreSQL classes seems to have changed
>> recently....)
>>
>> Thanks for your help.
>> Brian
>>
>>
>>
>> Larry Dunnell wrote:
>>> You can write all your code without ever using the getSchemas() call.
>>> The Database.getSchemas() method was added to ease porting for adopters
>>> moving from WTP. It is really just a shortcut for getting all the
>>> schemas in all the catalogs. In the case of databases that don't
>>> support Catalog then it is simply getting all the schemas in the default
>>> Catalog. A default Catalog can be identified by checking the quantity
>>> of Catalogs (should be 1 for the default Catalog) and that the name of
>>> the Catalog is null.
>>>
>>>
>>>
|
|
|
| Re: catalogs vs. schemas [message #50192 is a reply to message #50075] |
Thu, 25 September 2008 13:53 |
| Eclipse User |
|
|
|
Brian,
I would say that everything is working as expected. The getSchemas() call
probably depends on the catalog loader. Since the catalog loaders in DTP
have been ported to support catalogs, I'm not too surprised that the
getSchemas() call doesn't work for most databases.
As far as MySQL, it's behavior is the result of it not supporting schemas
or catalogs. My guess is the DTP code checks the database definition to
see if schemas are supported and if not then it branches to a special case
where there is a default schema which has the same name as the database.
I would say this a defect and that there should be a default catalog with
a default schema under that instead of returning no catalogs. There
should be no reason for non-legacy code to call getSchemas() instead of
getCatalogs(). Please open a defect.
Larry Dunnell
> Brian Vosburgh wrote:
>> I have finally gotten around to playing with this stuff....
>>
>> I am working on the Dali code that determines the "default" catalog
>> and/or schema for a database connection. We use this information to
>> validate the user's mappings. For example, if the Employee class/entity
>> is mapped to the EMP table:
>>
>> @Entity
>> @Table(EMP)
>> public class Employee {...}
>>
>> we would like to verify, using the DTP Database API, whether the table
>> exists. This means we need to determine what schema (and, possibly,
>> catalog)
>> would contain the specified table by default. We would also like to
>> determine whether a particular database "supports" catalogs, so we
>> can possibly enable/disable various UI components.
>>
>> I have tested the Database API on the following databases:
>>
>> Derby 10.1
>> MySQL 5.0
>> Oracle 10g
>> PostgreSQL 8.2
>> Sybase ASE 15
>>
>> Slightly contrary to what you have described, Derby, Oracle, and PostgreSQL
>> exhibit the following:
>>
>> Database.getSchemas() returns an empty collection
>> Database.getCatalogs() returns a single catalog with an empty string
>> for a name; this catalog contains all the schemas
>>
>> Sybase:
>>
>> Database.getSchemas() returns an empty collection
>> Database.getCatalogs() returns a collection of catalogs
>> corresponding to
>> the databases on the server, each containing at least a single
>> schema "dbo"
>> (some also containing a "guest" schema etc.)
>>
>> MySQL:
>>
>> Database.getSchemas() returns a single schema with the same name as the
>> database itself
>> Database.getCatalogs() returns an empty collection
>>
>> Assuming that the "default" catalog is similar to what you described (i.e.
>> the database has a single catalog with an empty string for a name), all of
>> the databases I have tested, with the exception of MySQL, seem to behave
>> as one might expect. MySQL's behavior seems completely inconsistent with
>> the other databases.... Is this a bug or expected behavior?
>>
>> Unfortunately, Database.getSchemas() does not perform at all like you
>> described. Is this a bug or expected behavior? Also, is this behavior a
>> documented part of the API that Dali can rely on in the future? (Note
>> that the behavior of the PostgreSQL classes seems to have changed
>> recently....)
>>
>> Thanks for your help.
>> Brian
>>
>>
>>
>> Larry Dunnell wrote:
>>> You can write all your code without ever using the getSchemas() call.
>>> The Database.getSchemas() method was added to ease porting for
>>> adopters moving from WTP. It is really just a shortcut for getting
>>> all the schemas in all the catalogs. In the case of databases that
>>> don't support Catalog then it is simply getting all the schemas in the
>>> default Catalog. A default Catalog can be identified by checking the
>>> quantity of Catalogs (should be 1 for the default Catalog) and that
>>> the name of the Catalog is null.
>>>
>>>
>>>
|
|
|
| Re: catalogs vs. schemas [message #50222 is a reply to message #50133] |
Fri, 26 September 2008 01:13 |
| Eclipse User |
|
|
|
Originally posted by: first.last.oracle.com
I guess you're forgetting bug 238473 "ASE connection profile does not honor
the database name provided"? :-)
The fix for that recent bug seems to be my problem. I am setting a database.
This did not cause me problems before, but it did just now, until I stopped
specifying the database.
This just validates my earlier questions: How are Database.getCatalogs() and
Database.getSchemas() supposed to work? And where is this documented? And is
it behavior that Dali can depend on in the future? The description provided
by Larry earlier appears to be incorrect, as documented in my long-winded
post below.
Thanks.
Brian
Brian Fitzpatrick wrote:
> Nothing should have changed with the Sybase database support from 1.6 to
> 1.6.1, so that's confusing...
>
> Are you talking ASE or ASA? There's a difference. ASE has the potential of
> returning one or more catalogs. ASA doesn't.
>
> And I'll see if I can get some more clarification for you.
>
> --Fitz
>
> "Brian Vosburgh" <first.last@oracle.com> wrote in message
> news:gbe4ve$7vo$1@build.eclipse.org...
>> Anyone?
>>
>> I know the post is long; but it's pretty straightforward.
>>
>> Also, it appears that *someone* is working in this area; because
>> I just moved from 1.6.0 to 1.6.1RC3 and the "catalogs" returned by
>> Database.getCatalogs() for Sybase is *different*. Arrrgh! It used
>> to return a "catalog" for each database on the server; but now it
>> returns only a single "catalog". What is going on? What is
>> *supposed* to be going on? And how am I supposed to know?
>>
>> Thanks.
>> Brian
>>
>> Brian Vosburgh wrote:
>>> I have finally gotten around to playing with this stuff....
>>>
>>> I am working on the Dali code that determines the "default" catalog
>>> and/or schema for a database connection. We use this information to
>>> validate the user's mappings. For example, if the Employee class/entity
>>> is mapped to the EMP table:
>>>
>>> @Entity
>>> @Table(EMP)
>>> public class Employee {...}
>>>
>>> we would like to verify, using the DTP Database API, whether the table
>>> exists. This means we need to determine what schema (and, possibly,
>>> catalog)
>>> would contain the specified table by default. We would also like to
>>> determine whether a particular database "supports" catalogs, so we
>>> can possibly enable/disable various UI components.
>>>
>>> I have tested the Database API on the following databases:
>>>
>>> Derby 10.1
>>> MySQL 5.0
>>> Oracle 10g
>>> PostgreSQL 8.2
>>> Sybase ASE 15
>>>
>>> Slightly contrary to what you have described, Derby, Oracle, and
>>> PostgreSQL
>>> exhibit the following:
>>>
>>> Database.getSchemas() returns an empty collection
>>> Database.getCatalogs() returns a single catalog with an empty string
>>> for a name; this catalog contains all the schemas
>>>
>>> Sybase:
>>>
>>> Database.getSchemas() returns an empty collection
>>> Database.getCatalogs() returns a collection of catalogs corresponding
>>> to
>>> the databases on the server, each containing at least a single
>>> schema "dbo"
>>> (some also containing a "guest" schema etc.)
>>>
>>> MySQL:
>>>
>>> Database.getSchemas() returns a single schema with the same name as
>>> the
>>> database itself
>>> Database.getCatalogs() returns an empty collection
>>>
>>> Assuming that the "default" catalog is similar to what you described
>>> (i.e.
>>> the database has a single catalog with an empty string for a name), all
>>> of
>>> the databases I have tested, with the exception of MySQL, seem to behave
>>> as one might expect. MySQL's behavior seems completely inconsistent with
>>> the other databases.... Is this a bug or expected behavior?
>>>
>>> Unfortunately, Database.getSchemas() does not perform at all like you
>>> described. Is this a bug or expected behavior? Also, is this behavior a
>>> documented part of the API that Dali can rely on in the future? (Note
>>> that the behavior of the PostgreSQL classes seems to have changed
>>> recently....)
>>>
>>> Thanks for your help.
>>> Brian
>>>
>>>
>>>
>>> Larry Dunnell wrote:
>>>> You can write all your code without ever using the getSchemas() call.
>>>> The Database.getSchemas() method was added to ease porting for adopters
>>>> moving from WTP. It is really just a shortcut for getting all the
>>>> schemas in all the catalogs. In the case of databases that don't
>>>> support Catalog then it is simply getting all the schemas in the default
>>>> Catalog. A default Catalog can be identified by checking the quantity
>>>> of Catalogs (should be 1 for the default Catalog) and that the name of
>>>> the Catalog is null.
>>>>
>>>>
>>>>
>
>
|
|
|
| Re: catalogs vs. schemas [message #50425 is a reply to message #50192] |
Mon, 29 September 2008 14:59 |
| Eclipse User |
|
|
|
Originally posted by: first.last.oracle.com
Thanks for the help, Larry.
I've submitted bug 249013 [1] for further discussion of the MySQL stuff.
Brian
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=249013
Larry Dunnell wrote:
> Brian,
>
> I would say that everything is working as expected. The getSchemas()
> call probably depends on the catalog loader. Since the catalog loaders
> in DTP have been ported to support catalogs, I'm not too surprised that
> the getSchemas() call doesn't work for most databases.
>
> As far as MySQL, it's behavior is the result of it not supporting
> schemas or catalogs. My guess is the DTP code checks the database
> definition to see if schemas are supported and if not then it branches
> to a special case where there is a default schema which has the same
> name as the database. I would say this a defect and that there should
> be a default catalog with a default schema under that instead of
> returning no catalogs. There should be no reason for non-legacy code to
> call getSchemas() instead of getCatalogs(). Please open a defect.
>
> Larry Dunnell
>
>
>> Brian Vosburgh wrote:
>>> I have finally gotten around to playing with this stuff....
>>>
>>> I am working on the Dali code that determines the "default" catalog
>>> and/or schema for a database connection. We use this information to
>>> validate the user's mappings. For example, if the Employee class/entity
>>> is mapped to the EMP table:
>>>
>>> @Entity
>>> @Table(EMP)
>>> public class Employee {...}
>>>
>>> we would like to verify, using the DTP Database API, whether the table
>>> exists. This means we need to determine what schema (and, possibly,
>>> catalog)
>>> would contain the specified table by default. We would also like to
>>> determine whether a particular database "supports" catalogs, so we
>>> can possibly enable/disable various UI components.
>>>
>>> I have tested the Database API on the following databases:
>>>
>>> Derby 10.1
>>> MySQL 5.0
>>> Oracle 10g
>>> PostgreSQL 8.2
>>> Sybase ASE 15
>>>
>>> Slightly contrary to what you have described, Derby, Oracle, and
>>> PostgreSQL
>>> exhibit the following:
>>>
>>> Database.getSchemas() returns an empty collection
>>> Database.getCatalogs() returns a single catalog with an empty string
>>> for a name; this catalog contains all the schemas
>>>
>>> Sybase:
>>>
>>> Database.getSchemas() returns an empty collection
>>> Database.getCatalogs() returns a collection of catalogs
>>> corresponding to
>>> the databases on the server, each containing at least a
>>> single schema "dbo"
>>> (some also containing a "guest" schema etc.)
>>>
>>> MySQL:
>>>
>>> Database.getSchemas() returns a single schema with the same name
>>> as the
>>> database itself
>>> Database.getCatalogs() returns an empty collection
>>>
>>> Assuming that the "default" catalog is similar to what you described
>>> (i.e.
>>> the database has a single catalog with an empty string for a name),
>>> all of
>>> the databases I have tested, with the exception of MySQL, seem to behave
>>> as one might expect. MySQL's behavior seems completely inconsistent with
>>> the other databases.... Is this a bug or expected behavior?
>>>
>>> Unfortunately, Database.getSchemas() does not perform at all like you
>>> described. Is this a bug or expected behavior? Also, is this behavior a
>>> documented part of the API that Dali can rely on in the future? (Note
>>> that the behavior of the PostgreSQL classes seems to have changed
>>> recently....)
>>>
>>> Thanks for your help.
>>> Brian
>>>
>>>
>>>
>>> Larry Dunnell wrote:
>>>> You can write all your code without ever using the getSchemas()
>>>> call. The Database.getSchemas() method was added to ease porting
>>>> for adopters moving from WTP. It is really just a shortcut for
>>>> getting all the schemas in all the catalogs. In the case of
>>>> databases that don't support Catalog then it is simply getting all
>>>> the schemas in the default Catalog. A default Catalog can be
>>>> identified by checking the quantity of Catalogs (should be 1 for the
>>>> default Catalog) and that the name of the Catalog is null.
>>>>
>>>>
>>>>
>
>
|
|
|
| Re: catalogs vs. schemas [message #592888 is a reply to message #49317] |
Tue, 26 August 2008 16:24 |
| Eclipse User |
|
|
|
Unfortunately, the getCatalogs() vs. getSchemas() calls all boil down to how
the JDBC driver itself provides that information.
There should always be a default catalog, even if the Database/JDBC driver
doesn't provide one, so you should (famous last words) always be able to
drill down from the catalogs level into schemas, tables, etc...
--Fitz
"Brian Vosburgh" <first.last@oracle.com> wrote in message
news:g91lsh$900$1@build.eclipse.org...
> Is there any documentation that explains clearly how and when the methods
> Database.getSchemas() and Database.getCatalogs() should be used? Are they
> both relevant for all databases (vendors?)? When do you use one and not
> the other? etc.
>
> Thanks.
> Brian
|
|
|
| Re: catalogs vs. schemas [message #592939 is a reply to message #49348] |
Sat, 30 August 2008 02:33 |
| Eclipse User |
|
|
|
Thanks for the response, Fitz. Let me see if I understand:
Database.getCatalogs() returns a set of catalogs corresponding to
the names returned by java.sql.DatabaseMetaData.getCatalogs().
Depending on the vendor, this may be empty.
Database.getSchemas() returns a set of schemas corresponding to the
schema names returned by java.sql.DatabaseMetaData.getSchemas() whose
catalog names are null. If every schema has a catalog, this will be
empty.
The schemas that do not have a catalog are returned by both
Database.getSchemas() and Catalog.getSchemas(), where the catalog is
some "default" catalog? Is there standard name for the "default" catalog?
And how do I know when a catalog is a "default" and when it actually
corresponds to a catalog name returned by the JDBC driver?
Thanks, again.
Brian
Brian Fitzpatrick wrote:
> Unfortunately, the getCatalogs() vs. getSchemas() calls all boil down to how
> the JDBC driver itself provides that information.
>
> There should always be a default catalog, even if the Database/JDBC driver
> doesn't provide one, so you should (famous last words) always be able to
> drill down from the catalogs level into schemas, tables, etc...
>
> --Fitz
>
> "Brian Vosburgh" <first.last@oracle.com> wrote in message
> news:g91lsh$900$1@build.eclipse.org...
>> Is there any documentation that explains clearly how and when the methods
>> Database.getSchemas() and Database.getCatalogs() should be used? Are they
>> both relevant for all databases (vendors?)? When do you use one and not
>> the other? etc.
>>
>> Thanks.
>> Brian
>
>
|
|
|
| Re: catalogs vs. schemas [message #592989 is a reply to message #49467] |
Tue, 02 September 2008 14:27 |
| Eclipse User |
|
|
|
You can write all your code without ever using the getSchemas() call. The
Database.getSchemas() method was added to ease porting for adopters moving
from WTP. It is really just a shortcut for getting all the schemas in all
the catalogs. In the case of databases that don't support Catalog then it
is simply getting all the schemas in the default Catalog. A default
Catalog can be identified by checking the quantity of Catalogs (should be
1 for the default Catalog) and that the name of the Catalog is null.
|
|
|
| Re: catalogs vs. schemas [message #593081 is a reply to message #49589] |
Wed, 17 September 2008 00:50 |
| Eclipse User |
|
|
|
I have finally gotten around to playing with this stuff....
I am working on the Dali code that determines the "default" catalog
and/or schema for a database connection. We use this information to
validate the user's mappings. For example, if the Employee class/entity
is mapped to the EMP table:
@Entity
@Table(EMP)
public class Employee {...}
we would like to verify, using the DTP Database API, whether the table
exists. This means we need to determine what schema (and, possibly, catalog)
would contain the specified table by default. We would also like to
determine whether a particular database "supports" catalogs, so we
can possibly enable/disable various UI components.
I have tested the Database API on the following databases:
Derby 10.1
MySQL 5.0
Oracle 10g
PostgreSQL 8.2
Sybase ASE 15
Slightly contrary to what you have described, Derby, Oracle, and PostgreSQL
exhibit the following:
Database.getSchemas() returns an empty collection
Database.getCatalogs() returns a single catalog with an empty string
for a name; this catalog contains all the schemas
Sybase:
Database.getSchemas() returns an empty collection
Database.getCatalogs() returns a collection of catalogs corresponding to
the databases on the server, each containing at least a single schema "dbo"
(some also containing a "guest" schema etc.)
MySQL:
Database.getSchemas() returns a single schema with the same name as the
database itself
Database.getCatalogs() returns an empty collection
Assuming that the "default" catalog is similar to what you described (i.e.
the database has a single catalog with an empty string for a name), all of
the databases I have tested, with the exception of MySQL, seem to behave
as one might expect. MySQL's behavior seems completely inconsistent with
the other databases.... Is this a bug or expected behavior?
Unfortunately, Database.getSchemas() does not perform at all like you
described. Is this a bug or expected behavior? Also, is this behavior a
documented part of the API that Dali can rely on in the future? (Note
that the behavior of the PostgreSQL classes seems to have changed
recently....)
Thanks for your help.
Brian
Larry Dunnell wrote:
> You can write all your code without ever using the getSchemas() call.
> The Database.getSchemas() method was added to ease porting for adopters
> moving from WTP. It is really just a shortcut for getting all the
> schemas in all the catalogs. In the case of databases that don't
> support Catalog then it is simply getting all the schemas in the default
> Catalog. A default Catalog can be identified by checking the quantity
> of Catalogs (should be 1 for the default Catalog) and that the name of
> the Catalog is null.
>
>
>
|
|
|
| Re: catalogs vs. schemas [message #593160 is a reply to message #49889] |
Wed, 24 September 2008 15:38 |
| Eclipse User |
|
|
|
Anyone?
I know the post is long; but it's pretty straightforward.
Also, it appears that *someone* is working in this area; because
I just moved from 1.6.0 to 1.6.1RC3 and the "catalogs" returned by
Database.getCatalogs() for Sybase is *different*. Arrrgh! It used
to return a "catalog" for each database on the server; but now it
returns only a single "catalog". What is going on? What is
*supposed* to be going on? And how am I supposed to know?
Thanks.
Brian
Brian Vosburgh wrote:
> I have finally gotten around to playing with this stuff....
>
> I am working on the Dali code that determines the "default" catalog
> and/or schema for a database connection. We use this information to
> validate the user's mappings. For example, if the Employee class/entity
> is mapped to the EMP table:
>
> @Entity
> @Table(EMP)
> public class Employee {...}
>
> we would like to verify, using the DTP Database API, whether the table
> exists. This means we need to determine what schema (and, possibly,
> catalog)
> would contain the specified table by default. We would also like to
> determine whether a particular database "supports" catalogs, so we
> can possibly enable/disable various UI components.
>
> I have tested the Database API on the following databases:
>
> Derby 10.1
> MySQL 5.0
> Oracle 10g
> PostgreSQL 8.2
> Sybase ASE 15
>
> Slightly contrary to what you have described, Derby, Oracle, and PostgreSQL
> exhibit the following:
>
> Database.getSchemas() returns an empty collection
> Database.getCatalogs() returns a single catalog with an empty string
> for a name; this catalog contains all the schemas
>
> Sybase:
>
> Database.getSchemas() returns an empty collection
> Database.getCatalogs() returns a collection of catalogs
> corresponding to
> the databases on the server, each containing at least a single
> schema "dbo"
> (some also containing a "guest" schema etc.)
>
> MySQL:
>
> Database.getSchemas() returns a single schema with the same name as the
> database itself
> Database.getCatalogs() returns an empty collection
>
> Assuming that the "default" catalog is similar to what you described (i.e.
> the database has a single catalog with an empty string for a name), all of
> the databases I have tested, with the exception of MySQL, seem to behave
> as one might expect. MySQL's behavior seems completely inconsistent with
> the other databases.... Is this a bug or expected behavior?
>
> Unfortunately, Database.getSchemas() does not perform at all like you
> described. Is this a bug or expected behavior? Also, is this behavior a
> documented part of the API that Dali can rely on in the future? (Note
> that the behavior of the PostgreSQL classes seems to have changed
> recently....)
>
> Thanks for your help.
> Brian
>
>
>
> Larry Dunnell wrote:
>> You can write all your code without ever using the getSchemas() call.
>> The Database.getSchemas() method was added to ease porting for
>> adopters moving from WTP. It is really just a shortcut for getting
>> all the schemas in all the catalogs. In the case of databases that
>> don't support Catalog then it is simply getting all the schemas in the
>> default Catalog. A default Catalog can be identified by checking the
>> quantity of Catalogs (should be 1 for the default Catalog) and that
>> the name of the Catalog is null.
>>
>>
>>
|
|
|
| Re: catalogs vs. schemas [message #593169 is a reply to message #50075] |
Thu, 25 September 2008 10:03 |
| Eclipse User |
|
|
|
Nothing should have changed with the Sybase database support from 1.6 to
1.6.1, so that's confusing...
Are you talking ASE or ASA? There's a difference. ASE has the potential of
returning one or more catalogs. ASA doesn't.
And I'll see if I can get some more clarification for you.
--Fitz
"Brian Vosburgh" <first.last@oracle.com> wrote in message
news:gbe4ve$7vo$1@build.eclipse.org...
> Anyone?
>
> I know the post is long; but it's pretty straightforward.
>
> Also, it appears that *someone* is working in this area; because
> I just moved from 1.6.0 to 1.6.1RC3 and the "catalogs" returned by
> Database.getCatalogs() for Sybase is *different*. Arrrgh! It used
> to return a "catalog" for each database on the server; but now it
> returns only a single "catalog". What is going on? What is
> *supposed* to be going on? And how am I supposed to know?
>
> Thanks.
> Brian
>
> Brian Vosburgh wrote:
>> I have finally gotten around to playing with this stuff....
>>
>> I am working on the Dali code that determines the "default" catalog
>> and/or schema for a database connection. We use this information to
>> validate the user's mappings. For example, if the Employee class/entity
>> is mapped to the EMP table:
>>
>> @Entity
>> @Table(EMP)
>> public class Employee {...}
>>
>> we would like to verify, using the DTP Database API, whether the table
>> exists. This means we need to determine what schema (and, possibly,
>> catalog)
>> would contain the specified table by default. We would also like to
>> determine whether a particular database "supports" catalogs, so we
>> can possibly enable/disable various UI components.
>>
>> I have tested the Database API on the following databases:
>>
>> Derby 10.1
>> MySQL 5.0
>> Oracle 10g
>> PostgreSQL 8.2
>> Sybase ASE 15
>>
>> Slightly contrary to what you have described, Derby, Oracle, and
>> PostgreSQL
>> exhibit the following:
>>
>> Database.getSchemas() returns an empty collection
>> Database.getCatalogs() returns a single catalog with an empty string
>> for a name; this catalog contains all the schemas
>>
>> Sybase:
>>
>> Database.getSchemas() returns an empty collection
>> Database.getCatalogs() returns a collection of catalogs corresponding
>> to
>> the databases on the server, each containing at least a single
>> schema "dbo"
>> (some also containing a "guest" schema etc.)
>>
>> MySQL:
>>
>> Database.getSchemas() returns a single schema with the same name as
>> the
>> database itself
>> Database.getCatalogs() returns an empty collection
>>
>> Assuming that the "default" catalog is similar to what you described
>> (i.e.
>> the database has a single catalog with an empty string for a name), all
>> of
>> the databases I have tested, with the exception of MySQL, seem to behave
>> as one might expect. MySQL's behavior seems completely inconsistent with
>> the other databases.... Is this a bug or expected behavior?
>>
>> Unfortunately, Database.getSchemas() does not perform at all like you
>> described. Is this a bug or expected behavior? Also, is this behavior a
>> documented part of the API that Dali can rely on in the future? (Note
>> that the behavior of the PostgreSQL classes seems to have changed
>> recently....)
>>
>> Thanks for your help.
>> Brian
>>
>>
>>
>> Larry Dunnell wrote:
>>> You can write all your code without ever using the getSchemas() call.
>>> The Database.getSchemas() method was added to ease porting for adopters
>>> moving from WTP. It is really just a shortcut for getting all the
>>> schemas in all the catalogs. In the case of databases that don't
>>> support Catalog then it is simply getting all the schemas in the default
>>> Catalog. A default Catalog can be identified by checking the quantity
>>> of Catalogs (should be 1 for the default Catalog) and that the name of
>>> the Catalog is null.
>>>
>>>
>>>
|
|
|
| Re: catalogs vs. schemas [message #593184 is a reply to message #50075] |
Thu, 25 September 2008 10:03 |
| Eclipse User |
|
|
|
Nothing should have changed with the Sybase database support from 1.6 to
1.6.1, so that's confusing...
Are you talking ASE or ASA? There's a difference. ASE has the potential of
returning one or more catalogs. ASA doesn't.
And I'll see if I can get some more clarification for you.
--Fitz
"Brian Vosburgh" <first.last@oracle.com> wrote in message
news:gbe4ve$7vo$1@build.eclipse.org...
> Anyone?
>
> I know the post is long; but it's pretty straightforward.
>
> Also, it appears that *someone* is working in this area; because
> I just moved from 1.6.0 to 1.6.1RC3 and the "catalogs" returned by
> Database.getCatalogs() for Sybase is *different*. Arrrgh! It used
> to return a "catalog" for each database on the server; but now it
> returns only a single "catalog". What is going on? What is
> *supposed* to be going on? And how am I supposed to know?
>
> Thanks.
> Brian
>
> Brian Vosburgh wrote:
>> I have finally gotten around to playing with this stuff....
>>
>> I am working on the Dali code that determines the "default" catalog
>> and/or schema for a database connection. We use this information to
>> validate the user's mappings. For example, if the Employee class/entity
>> is mapped to the EMP table:
>>
>> @Entity
>> @Table(EMP)
>> public class Employee {...}
>>
>> we would like to verify, using the DTP Database API, whether the table
>> exists. This means we need to determine what schema (and, possibly,
>> catalog)
>> would contain the specified table by default. We would also like to
>> determine whether a particular database "supports" catalogs, so we
>> can possibly enable/disable various UI components.
>>
>> I have tested the Database API on the following databases:
>>
>> Derby 10.1
>> MySQL 5.0
>> Oracle 10g
>> PostgreSQL 8.2
>> Sybase ASE 15
>>
>> Slightly contrary to what you have described, Derby, Oracle, and
>> PostgreSQL
>> exhibit the following:
>>
>> Database.getSchemas() returns an empty collection
>> Database.getCatalogs() returns a single catalog with an empty string
>> for a name; this catalog contains all the schemas
>>
>> Sybase:
>>
>> Database.getSchemas() returns an empty collection
>> Database.getCatalogs() returns a collection of catalogs corresponding
>> to
>> the databases on the server, each containing at least a single
>> schema "dbo"
>> (some also containing a "guest" schema etc.)
>>
>> MySQL:
>>
>> Database.getSchemas() returns a single schema with the same name as
>> the
>> database itself
>> Database.getCatalogs() returns an empty collection
>>
>> Assuming that the "default" catalog is similar to what you described
>> (i.e.
>> the database has a single catalog with an empty string for a name), all
>> of
>> the databases I have tested, with the exception of MySQL, seem to behave
>> as one might expect. MySQL's behavior seems completely inconsistent with
>> the other databases.... Is this a bug or expected behavior?
>>
>> Unfortunately, Database.getSchemas() does not perform at all like you
>> described. Is this a bug or expected behavior? Also, is this behavior a
>> documented part of the API that Dali can rely on in the future? (Note
>> that the behavior of the PostgreSQL classes seems to have changed
>> recently....)
>>
>> Thanks for your help.
>> Brian
>>
>>
>>
>> Larry Dunnell wrote:
>>> You can write all your code without ever using the getSchemas() call.
>>> The Database.getSchemas() method was added to ease porting for adopters
>>> moving from WTP. It is really just a shortcut for getting all the
>>> schemas in all the catalogs. In the case of databases that don't
>>> support Catalog then it is simply getting all the schemas in the default
>>> Catalog. A default Catalog can be identified by checking the quantity
>>> of Catalogs (should be 1 for the default Catalog) and that the name of
>>> the Catalog is null.
>>>
>>>
>>>
|
|
|
| Re: catalogs vs. schemas [message #593196 is a reply to message #50075] |
Thu, 25 September 2008 10:27 |
| Eclipse User |
|
|
|
sorry about the double post, having issues with my newsgroup reader
"Brian Vosburgh" <first.last@oracle.com> wrote in message
news:gbe4ve$7vo$1@build.eclipse.org...
> Anyone?
>
> I know the post is long; but it's pretty straightforward.
>
> Also, it appears that *someone* is working in this area; because
> I just moved from 1.6.0 to 1.6.1RC3 and the "catalogs" returned by
> Database.getCatalogs() for Sybase is *different*. Arrrgh! It used
> to return a "catalog" for each database on the server; but now it
> returns only a single "catalog". What is going on? What is
> *supposed* to be going on? And how am I supposed to know?
>
> Thanks.
> Brian
>
> Brian Vosburgh wrote:
>> I have finally gotten around to playing with this stuff....
>>
>> I am working on the Dali code that determines the "default" catalog
>> and/or schema for a database connection. We use this information to
>> validate the user's mappings. For example, if the Employee class/entity
>> is mapped to the EMP table:
>>
>> @Entity
>> @Table(EMP)
>> public class Employee {...}
>>
>> we would like to verify, using the DTP Database API, whether the table
>> exists. This means we need to determine what schema (and, possibly,
>> catalog)
>> would contain the specified table by default. We would also like to
>> determine whether a particular database "supports" catalogs, so we
>> can possibly enable/disable various UI components.
>>
>> I have tested the Database API on the following databases:
>>
>> Derby 10.1
>> MySQL 5.0
>> Oracle 10g
>> PostgreSQL 8.2
>> Sybase ASE 15
>>
>> Slightly contrary to what you have described, Derby, Oracle, and
>> PostgreSQL
>> exhibit the following:
>>
>> Database.getSchemas() returns an empty collection
>> Database.getCatalogs() returns a single catalog with an empty string
>> for a name; this catalog contains all the schemas
>>
>> Sybase:
>>
>> Database.getSchemas() returns an empty collection
>> Database.getCatalogs() returns a collection of catalogs corresponding
>> to
>> the databases on the server, each containing at least a single
>> schema "dbo"
>> (some also containing a "guest" schema etc.)
>>
>> MySQL:
>>
>> Database.getSchemas() returns a single schema with the same name as
>> the
>> database itself
>> Database.getCatalogs() returns an empty collection
>>
>> Assuming that the "default" catalog is similar to what you described
>> (i.e.
>> the database has a single catalog with an empty string for a name), all
>> of
>> the databases I have tested, with the exception of MySQL, seem to behave
>> as one might expect. MySQL's behavior seems completely inconsistent with
>> the other databases.... Is this a bug or expected behavior?
>>
>> Unfortunately, Database.getSchemas() does not perform at all like you
>> described. Is this a bug or expected behavior? Also, is this behavior a
>> documented part of the API that Dali can rely on in the future? (Note
>> that the behavior of the PostgreSQL classes seems to have changed
>> recently....)
>>
>> Thanks for your help.
>> Brian
>>
>>
>>
>> Larry Dunnell wrote:
>>> You can write all your code without ever using the getSchemas() call.
>>> The Database.getSchemas() method was added to ease porting for adopters
>>> moving from WTP. It is really just a shortcut for getting all the
>>> schemas in all the catalogs. In the case of databases that don't
>>> support Catalog then it is simply getting all the schemas in the default
>>> Catalog. A default Catalog can be identified by checking the quantity
>>> of Catalogs (should be 1 for the default Catalog) and that the name of
>>> the Catalog is null.
>>>
>>>
>>>
|
|
|
| Re: catalogs vs. schemas [message #593204 is a reply to message #50075] |
Thu, 25 September 2008 13:53 |
| Eclipse User |
|
|
|
Brian,
I would say that everything is working as expected. The getSchemas() call
probably depends on the catalog loader. Since the catalog loaders in DTP
have been ported to support catalogs, I'm not too surprised that the
getSchemas() call doesn't work for most databases.
As far as MySQL, it's behavior is the result of it not supporting schemas
or catalogs. My guess is the DTP code checks the database definition to
see if schemas are supported and if not then it branches to a special case
where there is a default schema which has the same name as the database.
I would say this a defect and that there should be a default catalog with
a default schema under that instead of returning no catalogs. There
should be no reason for non-legacy code to call getSchemas() instead of
getCatalogs(). Please open a defect.
Larry Dunnell
> Brian Vosburgh wrote:
>> I have finally gotten around to playing with this stuff....
>>
>> I am working on the Dali code that determines the "default" catalog
>> and/or schema for a database connection. We use this information to
>> validate the user's mappings. For example, if the Employee class/entity
>> is mapped to the EMP table:
>>
>> @Entity
>> @Table(EMP)
>> public class Employee {...}
>>
>> we would like to verify, using the DTP Database API, whether the table
>> exists. This means we need to determine what schema (and, possibly,
>> catalog)
>> would contain the specified table by default. We would also like to
>> determine whether a particular database "supports" catalogs, so we
>> can possibly enable/disable various UI components.
>>
>> I have tested the Database API on the following databases:
>>
>> Derby 10.1
>> MySQL 5.0
>> Oracle 10g
>> PostgreSQL 8.2
>> Sybase ASE 15
>>
>> Slightly contrary to what you have described, Derby, Oracle, and PostgreSQL
>> exhibit the following:
>>
>> Database.getSchemas() returns an empty collection
>> Database.getCatalogs() returns a single catalog with an empty string
>> for a name; this catalog contains all the schemas
>>
>> Sybase:
>>
>> Database.getSchemas() returns an empty collection
>> Database.getCatalogs() returns a collection of catalogs
>> corresponding to
>> the databases on the server, each containing at least a single
>> schema "dbo"
>> (some also containing a "guest" schema etc.)
>>
>> MySQL:
>>
>> Database.getSchemas() returns a single schema with the same name as the
>> database itself
>> Database.getCatalogs() returns an empty collection
>>
>> Assuming that the "default" catalog is similar to what you described (i.e.
>> the database has a single catalog with an empty string for a name), all of
>> the databases I have tested, with the exception of MySQL, seem to behave
>> as one might expect. MySQL's behavior seems completely inconsistent with
>> the other databases.... Is this a bug or expected behavior?
>>
>> Unfortunately, Database.getSchemas() does not perform at all like you
>> described. Is this a bug or expected behavior? Also, is this behavior a
>> documented part of the API that Dali can rely on in the future? (Note
>> that the behavior of the PostgreSQL classes seems to have changed
>> recently....)
>>
>> Thanks for your help.
>> Brian
>>
>>
>>
>> Larry Dunnell wrote:
>>> You can write all your code without ever using the getSchemas() call.
>>> The Database.getSchemas() method was added to ease porting for
>>> adopters moving from WTP. It is really just a shortcut for getting
>>> all the schemas in all the catalogs. In the case of databases that
>>> don't support Catalog then it is simply getting all the schemas in the
>>> default Catalog. A default Catalog can be identified by checking the
>>> quantity of Catalogs (should be 1 for the default Catalog) and that
>>> the name of the Catalog is null.
>>>
>>>
>>>
|
|
|
| Re: catalogs vs. schemas [message #593215 is a reply to message #50133] |
Fri, 26 September 2008 01:13 |
| Eclipse User |
|
|
|
I guess you're forgetting bug 238473 "ASE connection profile does not honor
the database name provided"? :-)
The fix for that recent bug seems to be my problem. I am setting a database.
This did not cause me problems before, but it did just now, until I stopped
specifying the database.
This just validates my earlier questions: How are Database.getCatalogs() and
Database.getSchemas() supposed to work? And where is this documented? And is
it behavior that Dali can depend on in the future? The description provided
by Larry earlier appears to be incorrect, as documented in my long-winded
post below.
Thanks.
Brian
Brian Fitzpatrick wrote:
> Nothing should have changed with the Sybase database support from 1.6 to
> 1.6.1, so that's confusing...
>
> Are you talking ASE or ASA? There's a difference. ASE has the potential of
> returning one or more catalogs. ASA doesn't.
>
> And I'll see if I can get some more clarification for you.
>
> --Fitz
>
> "Brian Vosburgh" <first.last@oracle.com> wrote in message
> news:gbe4ve$7vo$1@build.eclipse.org...
>> Anyone?
>>
>> I know the post is long; but it's pretty straightforward.
>>
>> Also, it appears that *someone* is working in this area; because
>> I just moved from 1.6.0 to 1.6.1RC3 and the "catalogs" returned by
>> Database.getCatalogs() for Sybase is *different*. Arrrgh! It used
>> to return a "catalog" for each database on the server; but now it
>> returns only a single "catalog". What is going on? What is
>> *supposed* to be going on? And how am I supposed to know?
>>
>> Thanks.
>> Brian
>>
>> Brian Vosburgh wrote:
>>> I have finally gotten around to playing with this stuff....
>>>
>>> I am working on the Dali code that determines the "default" catalog
>>> and/or schema for a database connection. We use this information to
>>> validate the user's mappings. For example, if the Employee class/entity
>>> is mapped to the EMP table:
>>>
>>> @Entity
>>> @Table(EMP)
>>> public class Employee {...}
>>>
>>> we would like to verify, using the DTP Database API, whether the table
>>> exists. This means we need to determine what schema (and, possibly,
>>> catalog)
>>> would contain the specified table by default. We would also like to
>>> determine whether a particular database "supports" catalogs, so we
>>> can possibly enable/disable various UI components.
>>>
>>> I have tested the Database API on the following databases:
>>>
>>> Derby 10.1
>>> MySQL 5.0
>>> Oracle 10g
>>> PostgreSQL 8.2
>>> Sybase ASE 15
>>>
>>> Slightly contrary to what you have described, Derby, Oracle, and
>>> PostgreSQL
>>> exhibit the following:
>>>
>>> Database.getSchemas() returns an empty collection
>>> Database.getCatalogs() returns a single catalog with an empty string
>>> for a name; this catalog contains all the schemas
>>>
>>> Sybase:
>>>
>>> Database.getSchemas() returns an empty collection
>>> Database.getCatalogs() returns a collection of catalogs corresponding
>>> to
>>> the databases on the server, each containing at least a single
>>> schema "dbo"
>>> (some also containing a "guest" schema etc.)
>>>
>>> MySQL:
>>>
>>> Database.getSchemas() returns a single schema with the same name as
>>> the
>>> database itself
>>> Database.getCatalogs() returns an empty collection
>>>
>>> Assuming that the "default" catalog is similar to what you described
>>> (i.e.
>>> the database has a single catalog with an empty string for a name), all
>>> of
>>> the databases I have tested, with the exception of MySQL, seem to behave
>>> as one might expect. MySQL's behavior seems completely inconsistent with
>>> the other databases.... Is this a bug or expected behavior?
>>>
>>> Unfortunately, Database.getSchemas() does not perform at all like you
>>> described. Is this a bug or expected behavior? Also, is this behavior a
>>> documented part of the API that Dali can rely on in the future? (Note
>>> that the behavior of the PostgreSQL classes seems to have changed
>>> recently....)
>>>
>>> Thanks for your help.
>>> Brian
>>>
>>>
>>>
>>> Larry Dunnell wrote:
>>>> You can write all your code without ever using the getSchemas() call.
>>>> The Database.getSchemas() method was added to ease porting for adopters
>>>> moving from WTP. It is really just a shortcut for getting all the
>>>> schemas in all the catalogs. In the case of databases that don't
>>>> support Catalog then it is simply getting all the schemas in the default
>>>> Catalog. A default Catalog can be identified by checking the quantity
>>>> of Catalogs (should be 1 for the default Catalog) and that the name of
>>>> the Catalog is null.
>>>>
>>>>
>>>>
>
>
|
|
|
| Re: catalogs vs. schemas [message #593297 is a reply to message #50192] |
Mon, 29 September 2008 14:59 |
| Eclipse User |
|
|
|
Thanks for the help, Larry.
I've submitted bug 249013 [1] for further discussion of the MySQL stuff.
Brian
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=249013
Larry Dunnell wrote:
> Brian,
>
> I would say that everything is working as expected. The getSchemas()
> call probably depends on the catalog loader. Since the catalog loaders
> in DTP have been ported to support catalogs, I'm not too surprised that
> the getSchemas() call doesn't work for most databases.
>
> As far as MySQL, it's behavior is the result of it not supporting
> schemas or catalogs. My guess is the DTP code checks the database
> definition to see if schemas are supported and if not then it branches
> to a special case where there is a default schema which has the same
> name as the database. I would say this a defect and that there should
> be a default catalog with a default schema under that instead of
> returning no catalogs. There should be no reason for non-legacy code to
> call getSchemas() instead of getCatalogs(). Please open a defect.
>
> Larry Dunnell
>
>
>> Brian Vosburgh wrote:
>>> I have finally gotten around to playing with this stuff....
>>>
>>> I am working on the Dali code that determines the "default" catalog
>>> and/or schema for a database connection. We use this information to
>>> validate the user's mappings. For example, if the Employee class/entity
>>> is mapped to the EMP table:
>>>
>>> @Entity
>>> @Table(EMP)
>>> public class Employee {...}
>>>
>>> we would like to verify, using the DTP Database API, whether the table
>>> exists. This means we need to determine what schema (and, possibly,
>>> catalog)
>>> would contain the specified table by default. We would also like to
>>> determine whether a particular database "supports" catalogs, so we
>>> can possibly enable/disable various UI components.
>>>
>>> I have tested the Database API on the following databases:
>>>
>>> Derby 10.1
>>> MySQL 5.0
>>> Oracle 10g
>>> PostgreSQL 8.2
>>> Sybase ASE 15
>>>
>>> Slightly contrary to what you have described, Derby, Oracle, and
>>> PostgreSQL
>>> exhibit the following:
>>>
>>> Database.getSchemas() returns an empty collection
>>> Database.getCatalogs() returns a single catalog with an empty string
>>> for a name; this catalog contains all the schemas
>>>
>>> Sybase:
>>>
>>> Database.getSchemas() returns an empty collection
>>> Database.getCatalogs() returns a collection of catalogs
>>> corresponding to
>>> the databases on the server, each containing at least a
>>> single schema "dbo"
>>> (some also containing a "guest" schema etc.)
>>>
>>> MySQL:
>>>
>>> Database.getSchemas() returns a single schema with the same name
>>> as the
>>> database itself
>>> Database.getCatalogs() returns an empty collection
>>>
>>> Assuming that the "default" catalog is similar to what you described
>>> (i.e.
>>> the database has a single catalog with an empty string for a name),
>>> all of
>>> the databases I have tested, with the exception of MySQL, seem to behave
>>> as one might expect. MySQL's behavior seems completely inconsistent with
>>> the other databases.... Is this a bug or expected behavior?
>>>
>>> Unfortunately, Database.getSchemas() does not perform at all like you
>>> described. Is this a bug or expected behavior? Also, is this behavior a
>>> documented part of the API that Dali can rely on in the future? (Note
>>> that the behavior of the PostgreSQL classes seems to have changed
>>> recently....)
>>>
>>> Thanks for your help.
>>> Brian
>>>
>>>
>>>
>>> Larry Dunnell wrote:
>>>> You can write all your code without ever using the getSchemas()
>>>> call. The Database.getSchemas() method was added to ease porting
>>>> for adopters moving from WTP. It is really just a shortcut for
>>>> getting all the schemas in all the catalogs. In the case of
>>>> databases that don't support Catalog then it is simply getting all
>>>> the schemas in the default Catalog. A default Catalog can be
>>>> identified by checking the quantity of Catalogs (should be 1 for the
>>>> default Catalog) and that the name of the Catalog is null.
>>>>
>>>>
>>>>
>
>
|
|
|
Goto Forum:
Current Time: Fri Oct 31 16:03:39 EDT 2025
Powered by FUDForum. Page generated in 0.27425 seconds |
Home