Looking at the CSV export from report_csv.php I only see CIs and attributes.
Looking at the "Create a new CSV-Profile" I see only CI types.
If they cannot be imported, is there any serious risk in updating them via SQL (for an initial load)? I need to import data on a few hundred patch panel connections and don't think human entry is viable with any accuracy.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Currently its not possible to import relations. The problem is not the implementation but an easy to manage description of the references. For a releation you have to reference the endpoints in a simple but unique way…….thats what im looking for.
Using SQL to import relations is only recommended, if the relation type has no attributes. If this is your case, please ask for details.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What has drawn me to PHP-CMDB (away from OneCMDB) is the ability to add attributes to references. In my case, I want to record data about server-to-switch connections. There are two attributes in particular that make more sense to associate with the connection itself, rather than either of those CIs:
- Cable Type (straight/crossover )
- Patch Panel Location
The UI of PHP-CMDB handles these requirements in a very satisfactory (and unique) way, so I am willing to roll up my sleeves a bit to make the SQL imports work.
My thought was this:
A CI of type "port" can have only one relation of type "connection", therefore my script would need to release/delete any existing connection from the "relation" table before changing. Once the relation has been created, the r_id will be known. This should enable an update to the "attr" table where a_classtype=2 and a_classtype_id=r_id.
The a_ta_id column appears to be the sort order for the attributes, which I would fetch from "type_attr".
Does that sound plausible?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
While delete any existing connections from the "relation" table don't forget to delete all entries from the "attr" table, where a_classtype=2 and a_classtype_id=r_id (the attributes of the connections)!
The a_ta_id column references to the entry in "type_attr" table, describing the complete attribute, which means: name, data type, order ….
E.g. the data type defines, which of the a_val_xxxx-fields in "attr" is used to display the value of an attribute (the a_val_text is filled in every case for the searches).
It's a good idea, to try it by hand with one or two relations and see, how the table entries look like…but i think, you have done this.
A hint: you can check the consistency of the database entries over the Webfrontend under "Administration / DB-Check".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is it possible to import relations via CSV files?
Looking at the CSV export from report_csv.php I only see CIs and attributes.
Looking at the "Create a new CSV-Profile" I see only CI types.
If they cannot be imported, is there any serious risk in updating them via SQL (for an initial load)? I need to import data on a few hundred patch panel connections and don't think human entry is viable with any accuracy.
Currently its not possible to import relations. The problem is not the implementation but an easy to manage description of the references. For a releation you have to reference the endpoints in a simple but unique way…….thats what im looking for.
Using SQL to import relations is only recommended, if the relation type has no attributes. If this is your case, please ask for details.
Thanks for that response.
What has drawn me to PHP-CMDB (away from OneCMDB) is the ability to add attributes to references. In my case, I want to record data about server-to-switch connections. There are two attributes in particular that make more sense to associate with the connection itself, rather than either of those CIs:
- Cable Type (straight/crossover )
- Patch Panel Location
The UI of PHP-CMDB handles these requirements in a very satisfactory (and unique) way, so I am willing to roll up my sleeves a bit to make the SQL imports work.
My thought was this:
A CI of type "port" can have only one relation of type "connection", therefore my script would need to release/delete any existing connection from the "relation" table before changing. Once the relation has been created, the r_id will be known. This should enable an update to the "attr" table where a_classtype=2 and a_classtype_id=r_id.
The a_ta_id column appears to be the sort order for the attributes, which I would fetch from "type_attr".
Does that sound plausible?
While delete any existing connections from the "relation" table don't forget to delete all entries from the "attr" table, where a_classtype=2 and a_classtype_id=r_id (the attributes of the connections)!
The a_ta_id column references to the entry in "type_attr" table, describing the complete attribute, which means: name, data type, order ….
E.g. the data type defines, which of the a_val_xxxx-fields in "attr" is used to display the value of an attribute (the a_val_text is filled in every case for the searches).
It's a good idea, to try it by hand with one or two relations and see, how the table entries look like…but i think, you have done this.
A hint: you can check the consistency of the database entries over the Webfrontend under "Administration / DB-Check".
Hi,
Do you have any news on this subject ? Is this project still alive ?
As what I see is very close to what I need, just need to be able to import relation.
Thanks !