Hi Svetlana,

Are you familiar with action TableProperties and attribute Schema? You can define this on the target (e.g. a single action for all tables) to indicate what schema will be owning the table. Note that HVR does not create the schema - it must exist - but the DDL includes the schema name.

FYI if the user you connect as on the source when capturing the table definitions is not the table owner then HVR will also capture the schema name (in an action TableProperties).

Based on your description I am cautiously optimistic that what we provides is your option 2. Please let me know.

Thank you,
Mark.

Mark,

Yes, we use TableProperty with Schema attribute in our code.

I tried to explain with details the issue that we are facing. But I will try to repeat it here again.

There are no issues with using REST API and working with a channel when table names are not duplicates (they have a different schema).

When we get a list of table names which are duplicates, but with different schema obviously, HVR creates Table Identifiers (its internal table names) by using table name and adding suffix with a number – see screenshot below.

Our problem is not with adding tables - instead it is with taking actions on tables after they are added and for that the script is trying to find Table ID by matching table’s Base Name. Because that’s the only information we can get on created tables:

Base Name and Table Group Name.

The script uses REST API to get tables of a channel and those are the properties that the objects have – as well as is what is stored in hvrdb.

You can see the problem here – if for those table objects the Base Name is the same, there is no way identify the table.

If Table ID had schema name along with a table name – not a numeric suffix – then it would solve the problem. Or if the a table object had Schema name along with Base name and Table group name, that also could work.

I hope I explained the problem to you.

Thanks,

Lana.

Thank you Svetlana for clarifying the issue. I now understand your challenge.

Let me discuss with engineering whether we have considered your use case and respond back. Please do note that due to summer vacations the coverage is a little lighter which may result in a delay in getting back to you.

Mark.

Svetlana,

If we gave you the option to dictate the table name HVR will use when you add a new table, would that address your concern? Note you could in that case of course decide for yourself to use a schema prefix.

However please do note that we use the table name you see in the UI for downstream uses including any burst table and external table(s). This adds suffixes to the table name, and some targets limit table names to 30 characters.

Thank you,
Mark.

Mark,

Yes, that would solve the issue that we have.

BTW, our targets are Databricks which does not have such limitation - 30 characters for table name.

Let me ask you this question though - why not to add another property for schema along with Base Name and Table Group Name?

That would definitely not affect any table name restrictions.

When do you think we would be able to have the fix?

Thank you,

Lana.

Lana,

This will take us a few months in the best case. Over the summer (on the northern hemisphere) we have a lighter engineering coverage i.e. less room for small improvements.

We'll aim to get this done before the end of the year though; hopefully long before the end.

Thanks,
Mark.

Mark,

What about this question:

Why not to add another property for schema name along with Base Name and Table Group Name?

Regards,

Lana.

Lana,

Adding schema would expand the name space. It would impact almost all HVR commands because any table reference now also needs a schema. All customers would have to adjust any automation with HVR. We're not going to do this.

Also, we prefer not to change the repository table structures if we can avoid it.

Hope this clarifies.
Mark.

Hello,

Quick question about this request - are there any updates on when it will be implemented?

Thank you.

Regards,

Lana.