I have a question about cTrader FIX API's Price field 44 in new order single message.
I found this in FIX Specification Version 2.16.1
https://help.ctrader.com/fix
enter image description here
My question is that if I submit merket order with Price field 44, can I control the slippage of this merket order?
And If I set Price field, bigger slippage than I set never occurs?
I want to know whether cTrader FIX API supports " Market Range " order and it can avoid to excessive slippage or not.
Thank you
The information in the cTrader specification document is ambiguous. You should contact their technical support to ask for clarification.
Tag 44 is only used for limit orders. There is no slippage in limit orders since the order is filled at a price better or equal to the requested one. If you need more information just create a thread in ctrader.com
Related
I have two collections
Customers
Products
I have a field called "orders" in each of my customer document and what this "orders" field does is that it stores a reference to the product Id which was ordered by a customer, now my question is since I'm referencing product Id and if I update the "title" of that product then it will also update in the customer's order history since I can't embed each order information since a customer may order thousands of products and it can hit 16mb mark in no time so what's the fix for this. Thanks.
Create an Orders Collection
Store ID of the user who made the order
Store ID of the product bought
I understand you are looking up the value of the product from the customer entity. You will always get the latest price if you are not storing the order/price historical transactions. Because your data model is designed this way to retrieve the latest price information.
My suggestion.
Orders place with product and price always need to be stored in history entity or like order lines and not allow any process to change it so that when you look up products that customers brought you can always get the historical price and price change of the product should not affect the previous order. Two options.
Store the order history in the current collection customers (or top say 50 order lines if you don't need all of history(write additional logic to handle this)
if "option1" is not feasible due to large no. of orders think of creating an order lines transaction table and refer order line for the product brought via DBref or lookup command.
Note: it would have helped if you have given no. of transactions in each collection currently and its expected rate of growth of documents in the collection QoQ.
You have orders and products. Orders are referencing products. Your problem is that the products get updated and now your orders reference the new product. The easiest way to combat this issue is to store full data in each order. Store all the key product-related information.
The advantage is that this kind of solution is extremely easy to visualize and implement. The disadvantage is that you have a lot of repetitive data since most of your products probably don't get updated.
If you store a product update history based on timestamps, then you could solve your problem. Products are identified now by 3 fields. The product ID, active start date and active end date. Or you could configure products in this way: product ID = product ID + "Version X" and store this version against each order.
If you use dates, then you will query for the product and find the product version that was active during the time period that the order occurred. If you use versions against the product, then you will simply query the database for the particular version of the product itself. I haven't used mongoDb so I'm not sure how you would achieve this in mongoDb exactly. Naively however, you can modify the product ID to include the version as well using # as a delimiter possibly.
The advantage of this solution is that you don't store too much of extra data. Considering that products won't be updated too often, I feel like this is the ideal solution to your problem
I have a table in a word document that has three colums and all fields are mailmerge fields from an external IT system.
There are three columns displaying the fields:
Charge Description
Charge Value (£)
Eiligible? (yes/no)
I am trying to create a field that adds up all eligibale charges so that only charge values that show a "yes" in the eligigble field are included. Does anyone know if this is possible? I have tried creating a formula but can't get it to work. Also, I would assume at some point an if statment is required so that it only includes the eligible charge.
Has anyone done anything similar before and if so, would they mind sharing how it was achieved?
Many thanks
You can do some things with expression fields (created in Word with CTRL-F9). This will look like {} and you can insert the expression. eg {{MERGFIELD charge} + {MERGEFIELD charge2}}. Since however you want to check multiple values and then create an expression, its probably easier to use a macro. The macro would contain your logic, then set the fields in the document accordingly.
Here are two external links since I can't reproduce a useful amount the content here because it's a verbose answer to a potentially deep question:
Expression Fields
Merge fields
I hope that helps.
This is similar to to this question which doesn't have any answers. I've read all about how to use cursors with the twitter, facebook, and disqus api's and also this article about how disqus generally built their cursors, but I still cannot seem to grok the concept of how they work and how to implement a similar solution in my own projects. Can someone explain specifically the different techniques and concepts behind them?
Lets first understand why offset pagination fails for large data sets with an example.
Clients provide two parameters limit for number of results and offset and for page offset.
For example, with offset = 40, limit = 20, we can tell the database to return the next 20 items, skipping the first 40.
Drawbacks:
Using LIMIT OFFSET doesn’t scale well for large
datasets. As the offset increases the farther you go within the
dataset, the database still has to read up to offset + count rows
from disk, before discarding the offset and only returning count
rows.
If items are being written to the dataset at a high frequency, the
page window becomes unreliable, potentially skipping or returning
duplicate results.
How Cursors solve this ?
Cursor-based pagination works by returning a pointer to a specific item in the dataset. On subsequent requests, the server returns results after the given pointer.
We will use parameters next_cursor along with limit as the parameters provided by client in this case.
Let’s assume we want to paginate from the most recent user to the oldest user.When client request for the first time , suppose we select the first page through query:
SELECT * FROM users
WHERE team_id = %team_id
ORDER BY id DESC
LIMIT %limit
Where limit is equal to limit plus one, to fetch one more result than the count specified by the client. The extra result isn’t returned in the result set, but we use the ID of the value as the next_cursor.
The response from the server would be:
{
"users": [...],
"next_cursor": "1234", # the user id of the extra result
}
The client would then provide next_cursor as cursor in the second request.
SELECT * FROM users
WHERE team_id = %team_id
AND id <= %cursor
ORDER BY id DESC
LIMIT %limit
With this, we’ve addressed the drawbacks of offset based pagination:
Instead of the window being calculated from scratch on each request based on the total number of items, we’re always fetching the next count rows after a specific reference point. If items are being written to the dataset at a high frequency, the overall position of the cursor in the set might change, but the pagination window adjusts accordingly.
This will scale well for large datasets. We’re using a WHERE clause to fetch rows with id values less than the last id from the previous page. This lets us leverage the index on the column and the database doesn’t have to read any rows that we’ve already seen.
For detailed explanation you can visit this wonderful engineering article from slack!
Here is an article about pagination: paginating-real-time-data-cursor-based-pagination
Cursors – we need to have at least one column with unique sequential values to implement cursor based pagination. This can be similar to Twitter’s max_id parameter or Facebook’s after parameter.
In general you should pass the current item or page number in the request as a param. Other usual param is the batch size of the page. Then on the server side backend you select and return the proper dataset, with an SQL query for example.
enter image description hereHere's what I am Done with. The cursor is working as a pointer and it points to that index. and limit will pick that many rows from that pointer. Let's say we have given id 10 and limit 5 then it will go to id 10 and pick 5 elements from there.
Some Graph API connections uses cursors by default. You can use 'limit' and 'before'/'after' parameters in your call. If you are still not clear, you can post your code here and I can explain with it.
I'm trying to read name, card number, expiry date etc on Credit Card. but always return 6d00 when call SCardTransmit.
I'm using pre-define AID, which i have googled to be valid (correct me if i'm wrong). here's the are :
AID_LIST = {
"A0000000421010",
"A0000000422010",
"A0000000031010",
"A0000000032010",
"A0000000041010",
"A0000000042010",
"A00000006900",
"A0000001850002"
}
Thanks in advance.
I am not familiar with this API you are using, but you will have to send the following sequence of APDU commands:
SELECT PSE (for contact card), specified by EMV in Book 1, 11.3. An example is "00A404000E315041592E5359532E444446303100"
With the SFI returned, you can read the records to find out the supported AIDs. But, you can do this by "trial and error" using the pre-defineds AID that you specified and call SELECT AID, following the guidelines on Book 1, 12.3.3.
You may either call the command "GET PROCESSING OPTIONS" to see what records are available to read or you can read all possible records calling the "READ RECORD" command making a scan of the possible records. In one of those records, you will have the data you are looking for.
Usually in the same record you will have stored the Cardholder name, PAN and Track 2 discretionary data (in which is contained the expiration date).
The tags are listed in Book 3.
Application Primary Account Number (PAN) - 5A
Cardholder name - 5F20
Track 2 Discretionary Data - 9F20
Usefull info about Track 2:
http://en.wikipedia.org/wiki/Magnetic_stripe_card
A sample of the sequence above:
http://code.google.com/p/javaemvreader/wiki/ExampleOutput
EMV Specs:
http://www.emvco.com/specifications.aspx?id=223
The possible return codes, such as 61XX, 9000, etc are listed in ISO 7816. Here's a good overview: http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_5_basic_organizations.aspx
You need to lookup/buy ISO 7816, the EMV specifications and your vendors card specifications otherwise you don't know what you are doing.
I working on e-commerce website using Satchmo. However, there are few customization required for my store.
While ordering a product I should be able to specify a delivery date (shipping date).
There can be only 20 (max_num_delievries) deliveries possible per day for a product. If number of deliveries for a particular date for a particular product exceeds 'max_num_delievries', user should not be able to select that date while ordering the product.
Can someone please help in this and guide me how to achieve this using Satchmo?
Thanks in advance..
I would try something like this:
1) create a local app (eg. delivery_date) with a model like "DeliveryDate" or so. For example localsite/delivery_date/models.py:
class DeliveryDate(models.Model):
product = models.ForeignKey(Product)
date = models.DateField()
order = models.ManyToManyField(Order)
class Meta:
unique_together = ("product", "date")
2) the validation of the max 20 existing orders... mhh, good question, maybe the best would be, to do it on the form? Override the clean method and check if this delivery date is associated with 20 orders already... maybe something like localsite/delivery_date/forms.py
class DeliveryDateForm(forms.ModelForm):
class Meta:
model = DeliveryDate
def clean(self):
super(DeliveryDateForm, self).clean()
... check here the order_set count
... but maybe the form isn't the best place to do this.
You also probably want to hide and auto-set the initial values for product and order yourself, and the user only being supposed to select a date.
3) Regarding satchmo... I would use signals to react after a product has been added to the cart (there is a signal just for this case), and add a listener which redirects the user to a view where he can select the date for this product. Look at the example here with the signal "cart_add_view": http://www.facebook.com/note.php?note_id=101466134049
Maybe ajax would be a good option here. With a hidden container in your page... which shows up after adding a product to the cart (only if the product hasn't already a DeliveryDate associated to this order/product), and asking the user to select a date.
This whole stuff would be on the listener: check if the product needs a delivery date, and if yes, send an ajax response to pop-up the window, and put in the repsonse-context the form, with the initial product and order hidden fields.
And to save the delivery-date you will need another ajax-view.
Well it's merely an idea how I would try to do it ;-) It will probably need adjustments here and there, of course. But hopefully it helps you further.
Regards,
Andrea