Groups as Replicants - novice quick question…

Am I correct in thinking that I can make a DT Group a Replicant, please?

Any disadvantages, dangers?

Is a replicated group considered good practice?

TIA!

You are correct - groups can be both duplicated and replicated. I’m not aware of any specific dangers or disadvantages - assuming replication is what you are looking for. A replication is (and I mention this only to be thorough, not because I think you don’t know) effectively merely a pointer to the original; any changes undertaken to the replicant will be undertaken to the original. Replication is only possible within a database, not across databases. Note too, that the contents of the replicated group are not marked as replicants (and can be replicated elsewhere in their own right).

To my knowledge, groups are treated as records internally - just like any other file you have in DT. As such, I see no reason not to replicate them. Maybe more to the point, DEVONtech have chosen to make this option available - and I’m pretty trusting of what they offer :slight_smile:

So - in my opinion - if a replication is what is useful to you, that is why the functionality is available - go ahead and use it. You can have great fun with all this: I’ve just replicated a group in a test database; I replicated it to a group tag, which leads to the contents of the original group being tagged with the inherited tags of the group tag.

3 Likes

Thanks so much, @Blanc!

Your full reply is much appreciated; thanks, too, for trying it out.

I had read the characteristics, attributes and instructions for Replicants in the Manual and Joe’s TCo book.

Everything you kindly write confirms how I hoped replicating Groups as opposed to files would work… I know just what to do now :slight_smile:

1 Like

One thing that may throw people… If you replicate a group, it’s contents won’t appear to be replicants, i.e., they won’t show the replicant property icon or have the name in red italics. However, since a replicant is an instance of an item, the contents are indeed replicated and changes made to files in it also affect the other instances.

1 Like

That certainly could throw ppl if I hadn’t already told them all :D:D

Wait… I’m supposed to read your whole post?!?? :thinking:
:wink: :stuck_out_tongue:

1 Like

Thanks, Jim (and @Blanc), I wasn’t aware of that. I’ll see if it makes a difference to what I want to do. I suspect it’ll be mostly (only) a few Groups and that once I’m in one in ‘each of’ its two places, I won’t mind :slight_smile: .

I assume there’s no way to mark a Group’s contents as Replicants? And that it’s not wise to do so?

1 Like

Good grief no - I keep going off on tangents and talking about irrelevant things like the price of a C64! I certainly wouldn’t read all that! :crazy_face:

(I am only playing with you - I appreciate your work here no end, enjoy being allowed to direct questions at you, and have repeatedly been grateful that you have expanded on my responses, some of which have even been known to be quite insufficient)

1 Like

I don’t think there is any helpful way (although a smart rule could tag all replicants); because each record in the replicated group can be replicated elsewhere in its own right (and will then be marked as a replicant), marking the contents of a replicated group will always be a double-edged banana.

Makes sense. Yes. And since I don’t want to become obsessive (so wonderful is the DT world that it’s hard not to at times), as long as I can see my files in ‘both’ places, I think that’s enough :slight_smile:

Your help appreciated, @Blanc

1 Like

I’ve now discovered a bit of a snag - as I started to create Replicants and Replicant Groups: Labels.

I built my (actually imported from EF) DT database with seven strict and strictly-labelled top levels.

(Seven, of course, because that’s the OS/Finder’s maximum. Fair enough. I have (always) made that limitation work :slight_smile: .)

But I have discovered that a Replicant can only/must have the same (colour of) Label as its ‘original’.

In the first case that I came across, I wanted to replicate a file (URL, actually) teaching Ear Training which is (a nicely-nested sub-Group) in my ‘Music’ top level Group (whose Label is yellow) into my Computer > Software > Music > Ear Training Group. My Computer top level Group’s Label is grey.

I’m a perfectionist (or try to be!) and really want to follow a rigorous labelling color scheme :slight_smile: !

I can’t have both, can I: one Label (colour) for the original and a different one for its Replicant?

No dice. A replicant is an instance of the same file, essentially they ARE the same file. Because of this, a change is being made to one file, not several.

Got it. Thanks, Jim! Makes sense. I shall have to thin again - so particular am I about colours and labelling :slight_smile: .

As I say, a small bump…

I use replicated groups all the time. I love being able to assemble folder hierarchies at will, irrespective of the fixed hierarchies imposed by the OS proper.

But I would ask - wouldn’t it make sense to automatically convert all folder members, including subfolders, to replicants (with the color change) - once the parent is replicated?

Which raises a related question - what happens to a member of a replicated folder, if that item is moved to a non-replicated folder? Does it retain its replicant relationships? If so…does it turn red once it’s moved? If not - does it become a duplicate?

That would be a development decision.

what happens to a member of a replicated folder, if that item is moved to a non-replicated folder? Does it retain its replicant relationships? If so…does it turn red once it’s moved? If not - does it become a duplicate?

None of the above (and easily tested). It just moves out as a normal group and the replicant parent groups no longer have it as a child.

1 Like