CSV import : choose the right data type!

WHAT DO YOU RECOMMEND

When we import a CSV,

  • ask if we want to put them in a existing collection
  • ask if we want to create object as a existing type
  • in this case, if this type already has a property with the same name of the columns from CSV : use this relation!

REAL WORLD USE CASES

CSV import is still very basic, and at the moment it’s best not to use it at all.
(I tried…)

Case study: I’m importing a database of bottles, with specific data (name, origin, characteristics, etc.).
The aim is to have an equivalent collection in Anytype.

If I import my CSV :

  • it will create page objects: rarely the right choice for CSV!
  • the relationships will all be textual and, as you can’t change the type, you’ll have to throw them out.
    Conclusion: delete everything.

Now, if I create a “bottle” type in Anytype, with relations that have the same name, when I import the CSV I’ll have to tell Anytype to save the lines as “bottles”.
Ideally, I’d even like to be able to map the columns of my CSV to Anytype relations, but that’s more complex.

RECOMMENDED ALTERNATIVES

Propose to map CSV columns to AT relation
Or let the user change the type of relation

Following this post :

I’ve always hoped that the CSV import would develop into a more powerful tool like the one you suggest. In the recent past I use to support a proprietary business application that had a method of importing CSV data into their business objects. It would first export a CSV “template” with column headers showing what would be Relation labels in the first row, Relation types in the second row, and any special notes associated with the Relation in the third row. You would then fill in the values in the rows below these like in this example:

Column 1 Column 2 Column 3 Column 4 Column 5
Object Type ID Name Phone Birthdate
Text UID Text Number:Phone Date
Enter object type Enter Object ID (optional) Persons Full Name Phone Number Birth Date
Contact Pat Jones 9495551234 10/15/2020

It even had the ability to do a round trip process with the data such that you could export your current Object Set to be included as part of the template, then modify any of the values, then re-import back into the selected Object which would update any of the affected Relations. It would prevent duplicating objects by either enforcing a unique value in the object (which Anytype does not enforce at this time), or it would include the unique Object ID as a column value (which I think is currently hidden by Anytype).

I Suppose I take it there’s no advancement?
In a few weeks I’ll have some large csv files to import into an application (Anytype or Notion).

Any update on this? I’d love to be able to import data and map it to type/relations, otherwise I’m not sure what the import tool use case is for.

Is there any news about this? I’m trying to import CSV files to transform them into a collection, but it’s all confusing. I tried importing a CSV file with 10 columns and approximately 49 rows and it said that it exceeded the number of supported lines.

I modified the file to just two lines to test and the error still persisted. I changed the formatting type and separator, and still the error kept happening.

Hopefully the team can find some time to give this import some love… I just started messing with it – attempting to set up a basic csv with the columns matching my created properties in anytype.

So far, it just duplicates all the properties I already created and has left me cleaning up several disconnected objects. I’m trying to work out a way to capture daily expenses and capture payments… was just trying to save some time by sampling my existing tracking (spreadsheet) to import a quick set of data. Oh well.

I tried the same thing, matching the names of text, number, select, multi-select, and checkbox properties. Only the text property successfully merged with my existing one, all the others were duplicated and turned into text properties.