standardize API Entry or Element

[dehann]

also see #401

[Affie]

My intention with entry was to differentiate between just adding the ‘pointer’ to the data and the complete data record.

[dehann]

HI @Affie , okay thanks -- could you perhaps update the Nouns in the wiki please, not sure I follow 100% but we can use your lead as a starting point for the Nouns?

Maybe we can just add a clear example here of when to use Entry and when to use Element ...

DF Guessing

Writing this without being sure:

Example 1

I have a new piece of data I want to store, should I call addDataEntry or addDataElement?

Example 2

I know there is a piece of data and trying to just get a copy and don't care exactly how it is retrieved -- getDataEntry or getDataElement

Example 3

I'm trying to discover what data is available stores, should I be searching with the listDataElements or listDataEntries.

[Affie]

Ok, will take a look.
Why not just addBigData! for the wrapper version?

[dehann]

Jip, that is what I did, see #405 -- and dont mind the error being fixed in #410 .

Although we still need to resolve Entry or Element for general use beyond the convenience wrapper.

[dehann]

Why not just addBigData! for the wrapper version?

Oh, should be more specific -- did we not decide against the wording "BigData" and opted for "Data" and and "Smalldata" Nouns instead?

Question here remains though, Element or Entry -- or at least what's the difference?

EDIT: PS, later we can reduce to addData! once we have firm footing on Entry vs Element vs Record.

[dehann]

So Entry is the "description" of a "Data Element". The Element itself (the big blob of bytes) is kept in the DataStore. The Entry description is kept in the DFG object (only a small object)?

[dehann]

If so, then lines like these should be cleaned up:

DistributedFactorGraphs.jl/src/BigData/services/AbstractBigDataEntries.jl

Line 53 in b8e256a

element = GeneralBigDataEntry(dfg, node, descr, mimeType=mimeType)

[Affie]

It seems confusing and I don't really understand your question.

Why don't we name it Key and Record?
Or whatever the generic standard is for databases.

[dehann]

It seems confusing and I don't really understand your question.

I had hard time figuring out the difference between Entry and Element and seems the code is bit muddled. My current understanding is that Entry is our own format to hold the DB key, description/label, mimeType etc:

DistributedFactorGraphs.jl/src/BigData/entities/AbstractBigDataEntries.jl

Lines 6 to 12 in 37bb5f4

	mutable struct GeneralBigDataEntry <: AbstractBigDataEntry
	key::Symbol
	storeKey::Symbol # Could swap this to string, but using it as an index later, so better as a symbol I believe.
	createdTimestamp::DateTime
	lastUpdatedTimestamp::DateTime
	mimeType::String
	end

<<<PS, DataEntry or DataEntryGeneral might be closer to the verbNoun naming convention -- we can sort that one out later.>>>

Why don't we name it Key and Record?

I think Key does not envelop enough, since that would only be a unique identifier. But these are related since we already have entry.key see above.

The question of Element vs "Record" is bit less clear cut. Unfortunately "Record" and Entry sound very much the same too. Currently it seems the code has Element playing role of a "Record".

My suggestion is we leave "Key" and "Record" as names used by the database technology used, in much the same way we have kept the name Vertex (perhaps Node) as name associated with the graphing technology underneath.

Lets hear if @GearsAD has an opinion on naming convention.

My suggestion for the short to medium term remains: #403 (comment)

[dehann]

add added aliases for addData! and fetchData as was suggested above.

[Affie]

Works for me, when I came up with the Entry thing I just named it the first word that came to mind, but I wanted a distinction from the then used Element. I don't really mind what its called and think Sam will know best as you suggest. As long as the functionality is there to add the "key" separately to the graph.

[dehann]

Sounds good, think we are on the same page -- thanks for adding the Entry and Element, it will find its rhythm soon enough. In an attempt to avoid confusion, how about one Noun from Entry/Element/Record (which seems quite similar to me), and then pick either Data/Blob as a replacement for what is currently called Element? I'm just thinking out loud -- this is likely a DFG v0.9.0 thing.

[Affie]

From them I like entry and blob
So then

• a dataEntry refers to the key+
• a dataBlob refers to the value that will be at some key+

So something like addDataBlob(dfg, label, entry=>blob)

getDataBlobs(dfg, label)

[GearsAD]

Yes, entry is what is saved in database (it's the details about the data) and element is the actual data itself (part that's saved on disk/etc.). I understand there's a bit of confusion about this because the terms are so similar. entry and blob are good.

[dehann]

entry=>blob sounds great. It's a 3-0 vote, thanks!