Can I Customise the Project Browser to show Owner?

[Nick B]

Is it possible to do this?

Specifically, what I would like to do is include the Owner in the object name in the Database models.

Owner corresponds to Schema in DDL that is imported via the "import DB schema from ODBC" function. This would be particularly helpful as objects with the same name can exist in different schemas, plus schemas are typically a useful grouping anyway.

Thanks, Nick.

[Geert Bellekens]

I don't think so.

Geert

[qwerty]

If you want to include the owner name in the element name then do so and the project browser will show it as such.

To apply a naming scheme that is based on the owner name you could write a script.

q.

[Nick B]

Right, so it needs to be in the name.

The downside of this I think is that having added it to the name (using a script, or as a new option on the import function perhaps), it would then have to be removed in order to forward engineer it back to the database (another script or another option).

The <<stereotype>> is already shown in the browser; the option to also/instead show owner (or other data items) might actually be the easiest for Sparx to implement, and something I will think about suggesting.

Alternatively, it occurs to me that I could probably import one schema at a time into separate packages - might give that a go.

Thanks to you both for the response.

[Geert Bellekens]

Alternatively, it occurs to me that I could probably import one schema at a time into separate packages - might give that a go.

That seems like the best option.

Geert

[qwerty]

In similar cases I also use tagged values.

q.

[Nick B]

In similar cases I also use tagged values.

That sounds interesting as Owner/Schema is already set up as a Tag i.e. under Properties=>General=>Tags ... I assume that's wwhat you mean by "Tags"?

How do you then actually use these?

Thanks.

[qwerty]

I don't know how you use data modeling. Likely with the build-in DDL generation. I can't recall if you can use tagged values with that (too long ago I used it). In most cases I used scripting to create code/DDL so that was never an issue as tagged values are available via the API.

q.

[Nick B]

OK, thanks to all who have replied. For your info, I have now submitted the following feature request through the normal channels:

==============
When running "Import DB schema from ODBC", and being asked to select the schemas to import, I think it would be useful to be able to import these different schemas into different packages/folders.

In DB terms, a schema is logically quite close to the concept of a "Package" (Java for example), and without separating them in this way, it is currently quite difficult to see which database objects are in which schemas - you have to open each object to examine the Owner.

This request would result in something like the following structure:
<<Data Model>>
     LogicalModel
     <<Database>>
          <<Schema>> Schema 1
                Functions
                Procedures
                Queries
                Sequences
                Tables
                Triggers
                Views
          <<Schema>> Schema 2
                Functions
                ... etc.

So, everything the same except for repeating Schemas.

I have tried importing each schema separately into a different <<DataModel>>, and while this could be considered "a workaround", it creates a lot of overhead structure for each within its own <<Data Model>> and <<Database>> stereotypes. The result of my request above is both cleaner and closer to DB concepts.
=================

[qwerty]

Sounds reasonable, though I think your breath is not long enough to see it realized before you get really used to any work around.

q.

[skiwi]

When running "Import DB schema from ODBC", and being asked to select the schemas to import, I think it would be useful to be able to import these different schemas into different packages/folders.

I fully support this feature request.

This is very timely for me as I was just investigating how the new database builder in EA 12 supported multiple schema in the same database.

[SCare]

This is very usefully for me!