[visit-developers] db_type_fullname in ExportDBAttributes

Cyrus D. Harrison cyrush at llnl.gov
Fri Oct 10 12:38:18 EDT 2008

You are correct, I searched for the wrong thing previously, I now see 
where it is set by the gui/cli and used in the network manager.
It seems like we could figure this out on the engine and eliminate it 
but that is more trouble than I am will to go through for this ticket -
so I will simply cutoff access via the cli (Unless there are further 

Hank Childs wrote:
> On Oct 10, 2008, at 8:37 AM, Cyrus D. Harrison wrote:
>> Hi Everyone,
>> It was brought up that exposing ExportDBAttributes::db_type_fullname 
>> in the cli is a bit confusing, so we have a ticket for removing it 
>> from cli land.
>> Investigating further - I don't think we are using db_type_fullname 
>> anywhere - and I am proposing just removing it from the state object 
>> all together.
>> Are there any objections to this? Did I overlook where it is actually 
>> used?
>> Just removing it from the cli requires hand editing the Py files , 
>> which is simple but breaks precedent a little b/c it looks
>> like all of them are autogenerated. Note: Either way removing this 
>> from the cli could break some old scripts.
> Hi Cyrus,
> Firing off the top of my head:
> I think the idea behind fullname is that is what the engine needs when 
> it loads the plugin.  But we didn't want the user to have to say 
> "Silo_1.0".  So we have another field where the user says "Silo".  I 
> think there is some code (where?) that looks at the short name and 
> converts it to the fullname.
> Restated, I think the fullname is being used, but not as part of the 
> UI.  And I think it is being populated in a mystery location.  I can 
> dig down on where if that is necessary.
> -Hank

More information about the visit-developers mailing list