Thread

So…

I’m home-brewing a bunch of entries to import, and having lots of fun! (I think I’m being ironic here…)  😊

One thing that arises is creating entry_id’s.

So the question is—Is an entry_id unique across a weblog, across a site, or across the entire EE installation?

I’m thinking the scope is EE-wide.

Did I guess right? Do I get a cookie??  😊

Yes, it’s installation-wide.  You might like to look at CSVGrab, or even putting your entries into MT Import Format, to let EE do the work for you.

Hey, Lisa…

Yes, it’s installation-wide.  You might like to look at CSVGrab, or even putting your entries into MT Import Format, to let EE do the work for you.

I’d seen CSVGrab before, but it looked to me as though it would be about as much work as doing INSERTs in the Database Query Form with the pre-massaged data I already have in a local Filemaker Pro database.

As for the MT Import, that never occurred to me. Now that I look at the format, it may be easier for inserting entries with multiple categories.

I’ll look into it further…

Thanks for the info!

I only mention those because there are many places that need to be “hit” when importing; those are both proven methods, so I’d at least recommend looking at what tables they hit. =)

I appreciate it! I guess I’d need to open up some code to find out which tables the MT import utility hits; not sure where that is, but I imagine I can find it.

I think I’m going to proceed cautiously with SQL INSERTs, since I have not only multiple categories per entry, but also related entries, custom fields, and ratings that should be added as part of the entry creation process.

So far I think I have a handle on all the tables I have to hit, except those for the Ratings Module, which I’ll be researching next.

Hey again, Lisa…

[UPDATED below…]

Well, I thought I was very clever, having spotted all the tables that need to be hit—until I got to exp_relationships.

Ack! What a nightmare!

rel_id  rel_parent_id  rel_child_id  rel_type  rel_data                      reverse_rel_data          
   5         6           5            blog       a:3:{s:5:"query";O:8:"DB_Cache":5…

...and that rel_data field data goes on for about a gajillion characters(!).

It almost looks as though—in order to create a relationship—EE redundantly stores the entire rest of the database in each of the rel_data fields. *gulp*  😉

Please tell me I only have to insert a minimal amount of data—like rel_id, rel_parent_id, rel_child_id and rel_type—and let EE fill in the rest…?

Otherwise, I might have to use the CP’s Edit form to individually choose 867 relationships.

Oy! The menu!  😊

Any hope for importing relationships?

————————-
Update:
————————-

Found this in core.functions.php:

function clear_caching($which, $sub_dir = '', $relationships=FALSE)
    {
    
(blah, blah, blah…)

            case 'relationships' : $DB->query("UPDATE exp_relationships SET rel_data = '', reverse_rel_data = ''");

I definitely ain’t no PHP guru, but clear_caching is only clearing the last two columns… So that makes me think all that complex data in rel_data (and reverse_rel_data when appropriate) is temporary, cached data, and not vital to the relationship.

And that leads me to believe all I need to insert is the first 4 columns.

Yes?

I’m still hoping a cookie is coming my way…

😉

No, rel_data is not optional, I am afraid. It is a serialized array, and thus looks more intimidating than it really is. You need to unserialize it before you can work with it. It’s not too difficult to figure out, but probably requires some familiarity with PHP.

Ow, ow, owwww…  😉

Okay… I can generally cobble together a kludge, so I’ll see what I can do.

Thanks for the help!