I am trying to build a match spec on a DETS table and I've ran into something that puzzles me.
The Structure of the table entries look as follows:
{'RECORD_KEY','BODY_TUPLE'}
the 'RECORD_KEY' term looks like this {shell,T1,T2,T3,T4,T5,T6}
If I match spec on this:
{{' _','_','$1','_','_','_'},'$2'}
ie: dets:match(Ref, {{'_','_','$1','_','_','_'},'$2'} )
I get all entries in the table.
However, now I try to add some other terms to the match spec so I can start adding guards like this:
Terms = {{' _','_','$1','_','_','_'},'$2'},
Gaurds = [],
Returns = ['$1'],
Pattern = [{Terms,Gaurds,Returns}],
Matches = dets:match(Ref, Terms),
which returns NO entries, even if I replace the '$1' with '$_'.
What am I doing wrong here?
Okay I feel kind of stupid, I've actually used ETS tables quite a bit last year and I forgot that ets:match and ets:select are two different functions. I should have used SELECT.
Related
I wanted to write the simplest possible function which let me return the desired value in a nameless table and, ideally, it should be something like this:
function RL_MyTool:Version(n)
return {"0.4.0", "20221003-0230", "13.5.5"}[n]
end
But, of course, that's not allowed in Lua...
So, off the top of my head, I can think on these two other possibilities:
1:
function RL_MyTool:Version(n)
local t = {"20221003-0230", "13.5.5"}
return t[n] or "0.4.0"
end
2:
function RL_MyTool:Version(n)
local n, t = n or 1, {"0.4.0", "20221003-0230", "13.5.5"}
return t[n]
end
Both of them slightly different from each other but doing the same, counting with the advantage of returning a default value if no argument is given, which is good. BUT... Do you think I could still have a possibility of writing it like in the very simplest fashion way above? Basically, what I'd like is not even have to use a single variable or table declaration along the function but still let me return the specified table entry when called.
Well, that's all. Of course if it's finally not possible (as I'm afraid) it won't be the end of the world 🙄, but I wanted to be sure I wasn't missing any Lua trick or something that let me do it more like I firstly imagined... Thanks!
P.S. Oh, I don't see how, but of course if it could be achieved without the necessity of even using a table at all, that would be equally valid or even better.
EDIT: BTW, for the record and based in #Piglet (great!) answer, I got to reduce it even more this way:
function RL_MyTool:Version(n)
return ({"0.4.0", "20221003-0230", "13.5.5"})[n or 1]
end
Improving code usability/maintenance a bit at the same time by avoiding duplicated values... Kind of a win-win-win 😁
Just put the table in parenthesis.
function RL_MyTool:Version(n)
return ({"0.4.0", "20221003-0230", "13.5.5"})[n] or "0.4.0"
end
But what is the purpose of this? Code should be easy to read and easy to work on. There is absolutely no reason to not use a local table. You don't have to pay a dollar for each line of code.
I have the following function for a hacky project:
% The Record variable is some known record with an associated table.
Query = qlc:q([Existing ||
Existing <- mnesia:table(Table),
ExistingFields = record_to_fields(Existing),
RecordFields = record_to_fields(Record),
ExistingFields == RecordFields
]).
The function record_to_fields/1 simply drops the record name and ID from the tuple so that I can compare the fields themselves. If anyone wants context, it's because I pre-generate a unique ID for a record before attempting to insert it into Mnesia, and I want to make sure that a record with identical fields (but different ID) does not exist.
This results in the following (redacted for clarity) stack trace:
{aborted, {{case_clause, {stuff}},
[{db, '-my_func/2-fun-1-',8, ...
Which points to the line where I declare Query, however there is no case clause in sight. What is causing this error?
(Will answer myself, but I appreciate a comment that could explain how I could achieve what I want)
EDIT: this wouldn't be necessary if I could simply mark certain fields as unique, and Mnesia had a dedicated insert/1 or create/1 function.
For your example, I think your solution is clearer anyway (although it seems you can pull the record_to_fields(Record) portion outside the comprehension so it isn't getting calculated over and over.)
Yes, list comprehensions can only have generators and assignments. But you can cheat a little by writing an assignment as a one-element generator. For instance, you can re-write your expression as this:
RecordFields = record_to_fields(Record),
Query = qlc:q([Existing ||
Existing <- mnesia:table(Table),
ExistingFields <- [record_to_fields(Existing)],
ExistingFields == RecordFields
]).
As it turns out, the QLC DSL does not allow assignments, only generators and filters; as per the documentation (emphasis mine):
Syntactically QLCs have the same parts as ordinary list
comprehensions:
[Expression || Qualifier1, Qualifier2, ...]
Expression (the template)
is any Erlang expression. Qualifiers are either filters or generators.
Filters are Erlang expressions returning boolean(). Generators have
the form Pattern <- ListExpression, where ListExpression is an
expression evaluating to a query handle or a list.
Which means we cannot variable assignments within a QLC query.
Thus my only option, insofar as I know, is to simply write out the query as:
Query = qlc:q([Existing ||
Existing <- mnesia:table(Table),
record_to_fields(Existing) == record_to_fields(Record)
]).
I don't know the name for this kind of search, but I see that it's getting pretty common.
Let's say I have records with the following file names:
'order_spec.rb', 'order.sass', 'orders_controller_spec.rb'
If I search with the following string 'oc' I would like the result to return 'orders_controller_spec.rb' due to match the o in orders and the c in controller.
If the string is 'os' then I'd like all 3 to match, 'order_spec.rb', 'order.sass', 'orders_controller_spec.rb'.
If the string is 'oco' then I'd like 'orders_controller_spec.rb'
What is the name for this kind of search and how would I go about getting this done in Postgresql?
This is a called a subsequence search. One simple way to do it in Postgres is to use the LIKE operator (or several of the other options in those docs) and fill the spaces between your letters with a wildcard, which for LIKE is %. To match anything with an o followed by an s in the words column, that would look like this:
SELECT * FROM table WHERE words LIKE '%o%s%';
This is a relatively expensive search, but you can improve performance with a varchar_pattern_ops or text_pattern_ops index to support faster pattern matching.
CREATE INDEX pattern_index ON table (words varchar_pattern_ops);
I would like to split a string by a separator and get only the last part. I
don't care about the rest. I know I can do:
local last
for p in string.gmatch('file_name_test', '_%w+$') do last = p end
Which works, but is, IMHO, ugly.
Is there a more elegant way to say:
local last = string.gmatch('file_name_test', '_%w+$')[1]
Which doesn't work because gmatch returns an iterator (and not a table).
Use string.match which is not an iterator:
local last = string.match('file_name_test', '_(%w+)$')
print (last) --> test
Although the other answers do give you a correct answer for your situation, I am going to propose an answer to your question. Which was to get the first item from an iterator.
And the answer is actually quite simple. Since an iterator is just something that continues to return until it returns nil, we just have to call it!
local first = string.gmatch('file_name_test', '_%w+$')()
I am quite confused however, because in your question you also ask about the last thing it will return. I'm sad to say you cannot do this without iterating over them all, because an iterator cannot "jump ahead".
The pattern _%w+$ will only ever return a single match. That's because you anchored it at the end of the string, so it can only either match or fail to match (if there isn't an underscore followed by at least one %w character at the end).
The g* series of pattern matching are for iterating over a sequence of matches. If you want all the matches all at once (returned as multiple return values), use the non-g-prefixed functions. Like string.match:
string.match('file_name_test', '_%w+$')
If there is no match, then you'll get nil back.
I am trying example provided in Graph Databases book (PDF page 51-52)with Neo4j 2.0.1 (latest). It appears that I cannot just copy paste the code sample from the book (I guess the syntax is no longer valid).
START bob=node:user(username='Bob'),
charlie=node:user(username='Charlie')
MATCH (bob)-[e:EMAILED]->(charlie)
RETURN e
Got #=> Index `user` does not exist.
So, I tried without 'user'
START bob=node(username='Bob'),
charlie=node(username='Charlie')
MATCH (bob)-[e:EMAILED]->(charlie)
RETURN e
Got #=> Invalid input 'u': expected whitespace, an unsigned integer, a parameter or '*'
Tried this but didn't work
START bob=node({username:'Bob'}),
(charlie=node({username:'Charlie'})
MATCH (bob)-[e:EMAILED]->(charlie)
RETURN e
Got #=> Invalid input ':': expected an identifier character, whitespace or '}'
I want to use START then MATCH to achieve this. Would appreciate little bit of direction to get started.
From version 2.0 syntax has changed.
http://docs.neo4j.org/chunked/stable/query-match.html
Your first query should look like this.
MATCH (bob {username:'Bob'})-[e:EMAILED]->(charlie {username:'Charlie'})
RETURN e
The query does not work out of the box because you'll need to create the user index first. This can't be done with Cypher though, see the documentation for more info. Your syntax is still valid, but Lucene indexes are considered legacy. Schema indexes replace them, but they are not fully mature yet (e.g. no wildcard searches, IN support, ...).
You'll want to use labels as well, in your case a User label. The query can be refactored to:
MATCH (b:User { username:'Bob' })-[e:EMAILED]->(c:User { username:'Charlie' })
RETURN e
For good performance, add a schema index on the username property as well:
CREATE INDEX ON :User(username)
Start is optional, as noted above. Given that it's listed under the "deprecated" section in the Cypher 2.0 refcard, I would try to avoid using it going forward just for safety purposes.
However, the refcard does state that you can prepend your Cypher query with "CYPHER 1.9" (without the quotes) in order to make explicit use of the older syntax.