[Spring JPA] [Crud Repository] Query Creation

Table 5. Supported keywords inside method names

Keyword	Sample	JPQL snippet
And	findByLastnameAndFirstname	… where x.lastname = ?1 and x.firstname = ?2
Or	findByLastnameOrFirstname	… where x.lastname = ?1 or x.firstname = ?2
Is,Equals	findByFirstname,findByFirstnameIs,findByFirstnameEquals	… where x.firstname = 1?
Between	findByStartDateBetween	… where x.startDate between 1? and ?2
LessThan	findByAgeLessThan	… where x.age < ?1
LessThanEqual	findByAgeLessThanEqual	… where x.age ⇐ ?1
GreaterThan	findByAgeGreaterThan	… where x.age > ?1
GreaterThanEqual	findByAgeGreaterThanEqual	… where x.age >= ?1
After	findByStartDateAfter	… where x.startDate > ?1
Before	findByStartDateBefore	… where x.startDate < ?1
IsNull	findByAgeIsNull	… where x.age is null
IsNotNull,NotNull	findByAge(Is)NotNull	… where x.age not null
Like	findByFirstnameLike	… where x.firstname like ?1
NotLike	findByFirstnameNotLike	… where x.firstname not like ?1
StartingWith	findByFirstnameStartingWith	… where x.firstname like ?1(parameter bound with appended %)
EndingWith	findByFirstnameEndingWith	… where x.firstname like ?1(parameter bound with prepended %)
Containing	findByFirstnameContaining	… where x.firstname like ?1(parameter bound wrapped in%)
OrderBy	findByAgeOrderByLastnameDesc	… where x.age = ?1 order by x.lastname desc
Not	findByLastnameNot	… where x.lastname <> ?1
In	findByAgeIn(Collection<Age> ages)	… where x.age in ?1
NotIn	findByAgeNotIn(Collection<Age> age)	… where x.age not in ?1
True	findByActiveTrue()	… where x.active = true
False	findByActiveFalse()	… where x.active = false
IgnoreCase	findByFirstnameIgnoreCase	… where UPPER(x.firstame) = UPPER(?1)

http://docs.spring.io/spring-data/jpa/docs/current/reference/html/#repositories.query-methods

[JPA] Persistence.xml One-to-many Relationship

https://en.wikibooks.org/wiki/Java_Persistence/OneToMany

[BAT file] Comment

REM Comment line 1
REM Comment line 2
:Label1
:Label2
:: Comment line 3
:: Comment line 4
IF EXIST C:\AUTOEXEC.BAT REM AUTOEXEC.BAT exists

are all allowed.
However,

IF EXIST C:\AUTOEXEC.BAT :: AUTOEXEC.BAT exists

will result in a Syntax error message.


http://www.robvanderwoude.com/comments.php

[FIX Protocol] What is Message Sequence?

Credit: http://www.fixtradingcommunity.org/pg/discussions/topicpost/164577/sequence-number

Quotes from FIX.4.2 specs

[Start quote from Section "FIX MESSAGE FORMAT AND DELIVERY > Sequence Numbers"]
All FIX messages are identified by a unique sequence number. Sequence numbers are initialized at the start of each FIX session (see Session Protocol section) starting at 1 (one) and increment throughout the session. Monitoring sequence numbers will enable parties to identify and react to missed messages and to gracefully synchronize applications when reconnecting during a FIX session.
Each session will establish an independent incoming and outgoing sequence series; participants will maintain a sequence series to assign to outgoing messages and a separate series to monitor for sequence gaps on incoming messages.
[End quote]

[Start Quote from section "Session Protocol > Message Recovery"]
During initialization, or in the middle of a FIX session, message gaps may occur which are detected via the tracking of incoming sequence numbers. The following section provides details on how to recover messages.
As previously stated, each FIX participant must maintain two sequence numbers for each FIX session, one each for incoming and outgoing messages which are initialized at ‘1’ at the beginning of the FIX session. Each message is assigned a unique (by connection) sequence number, which is incremented after each message. Likewise, every message received has a unique sequence number and the incoming sequence counter is incremented after each message.
When the incoming sequence number does not match the expected number corrective processing is required. Note that the SeqReset-Reset message (used only to recover from a disaster scenario vs. normal resend request processing) is an exception to this rule as it should be processed without regards to its MsgSeqNum. If the incoming message has a sequence number less than expected and the PossDupFlag is not set, it indicates a serious error. It is strongly recommended that the session be terminated and manual intervention be initiated. If the incoming sequence number is greater than expected, it indicates that messages were missed and retransmission of the messages is requested via the Resend Request (see the earlier section, Ordered Message Processing).
[End Quote]

If Sequence number(s) are changed on your side without following the above rules and and your counterparty does not abnormally change sequence numbers on their side, then the following situations would occur

1) Your side increases Outbound Sequence number - Your counterparty would send you a resend request

2) Your side decreases Outbound Sequence number - Your counterparty is expected to drop the Session

3) Your side increases next expected Inbound sequence number - receipt of the next message would cause your FIX engine to drop the session because the sequence number of the message received is less than the number your FIX engine is expecting.

4) Your side decreases next expected Inbound sequence number - receipt of next message would cause your FIX engine to send a resend request.

We have used this manually increasing / descreasing sequence numbers abnormally as part of certification tests to check that resend request processing and session disconnect are working properly at both ends.

[FIX Protocol] Fix Parser

http://fixparser.targetcompid.com/

I quite like its domain name, targetCompID.com, so FIX, and the parser is quite user-friendly I think

[FIX Protocol] CompIDs in the Message

Assumption (A=sellside, B=buyside, X=third party):

			SenderCompID (49)	OnBehalfOfCompID (115)	TargetCompID (56)	DeliverToCompID (128)
Send from A to B via X
1)		A sends to X	A		X	B
2)		X sends to B	X	A	B
B responds to A via X
1)	B sends to X		B		X	A
2)	X sends to A		X	B	A

[FIX Protocol] Understanding OrdStatus[39] and ExecType[150] in FIX4.4

Both are for Execution Report[8], while ...

OrdStatus[39] identifies current status of order.

Valid values:

0 = New

1 = Partially filled

2 = Filled

3 = Done for day

4 = Canceled

<5 has been removed~!>

6 = Pending Cancel (e.g. result of Order Cancel Request <F>)

7 = Stopped

8 = Rejected

9 = Suspended

A = Pending New

B = Calculated

C = Expired

D = Accepted for bidding

E = Pending Replace (e.g. result of Order Cancel/Replace Request <G>)

http://www.onixs.biz/fix-dictionary/4.4/tagNum_39.html

ExecType[150] describes the specific ExecutionRpt. (I guess it implies the action just executed on sell side ... Rather than the current status of that order, separated terms with different "nature")

Valid values:

0 = New

3 = Done for day

4 = Canceled

5 = Replace

6 = Pending Cancel (e.g. result of Order Cancel Request <F>)

7 = Stopped

8 = Rejected

9 = Suspended

A = Pending New

B = Calculated

C = Expired

D = Restated (ExecutionRpt sent unsolicited by sellside, with ExecRestatementReason <378> (378) set)

E = Pending Replace (e.g. result of Order Cancel/Replace Request <G>)

F = Trade (partial fill or fill)

G = Trade Correct (formerly an ExecTransType <20> (20))

H = Trade Cancel (formerly an ExecTransType <20>)

I = Order Status (formerly an ExecTransType <20>)

http://www.onixs.biz/fix-dictionary/4.4/tagNum_150.html

Oh, my supervisor gave me this one to read then ... And I have read for around an hour to figure out more on the difference between ExecType & OrdStatus ... together with the behaviour of amending orders: 

http://www.fixdeveloper.com/2014/05/fix-44-order-state-change-matrices.html

An example captured:

C.3 - Replace to decrease quantity 

C.3.a - Cancel/replace request sent whilst execution is being reported, the requested order qty exceeds the cum qty. Order is replaced then filled

Time	Message Received (ClOrdID, OrigClOrdID)	Message Sent (ClOrdID, OrigClOrdID)	Exec Type	OrdStatus	Order Qty	Cum Qty	Leaves Qty	Last Qty	Comment
1	New Order(X)				10000
2		Execution(X)	Rejected	Rejected	10000	0	0	0	If order is rejected
2		Execution(X)	New	New	10000	0	10000	0
3		Execution(X)	Trade	Partially Filled	10000	1000	9000	1000	Execution for 1000
4	Replace Request(Y,X)				8000				Request a decrease order quantity to 8000 (leaving 7000 open)
4		Execution(X)	Trade	Partially Filled	10000	1500	8500	500	Execution for 500 sent. Replace request and this execution report pass each other on the connection
5		Cancel Reject (Y,X)		Partially Filled					If request is rejected by salesperson
5		Execution (Y,X)	Pending Replace	Pending Replace	10000	1500	8500	0	"Pending replace" order status takes precedence over "partially filled" order status
6		Execution(X)	Trade	Pending Replace	10000	1600	8400	100	Execution for 100 occurs before cancel/replace request is accepted
7		Cancel Reject (Y,X)		Partially Filled					If request is rejected by trader/exchange
7		Execution (Y,X)	Replace	Partially Filled	8000	1600	6400	0	Replace is accepted as requested order qty exceeds cum qty
8		Execution (Y)	Trade	Filled	8000	8000	0	6400	Execution for 6400.