1) What is the difference between TimeZoneName and TzId properties of IDateTime inside Ical.Net.Interfaces.DataTypes?
2) Where can I find complete list for both TimeZoneName and TzId ?
What is the difference between TimeZoneName and TzId properties of
IDateTime inside Ical.Net.Interfaces.DataTypes?
TimeZoneName returns the value of TzId. It's a historical artifact; I consider it deprecated. I may remove it at some point.
Where can I find complete list for both TimeZoneName and TzId
TzId is a mutable property, but assigned values should represent one of the time zones available in NodaTime, which ical.net uses under the hood. These are the tzdb (IANA), BCL (Windows) and serialization databases.
If you want to enumerate all of the values in each time zone database, have a look at this gist for inspiration. (Additional questions about NodaTime should be asked separately. NodaTime internals have nothing to do with ical.net.)
Related
In the "ETSI GS CIM 009 V1.2.1 (2019-10). Context Information Management (CIM); NGSI-LD API" standard there is a chapter "4.11 NGSI-LD Temporal Query language".
The NGSI-LD Temporal Query language shall be supported by implementations. It is intended to define predicates
which allow testing whether Temporal Properties of NGSI-LD Entities, Properties and Relationships, are within certain
temporal constraints. In particular it can be used to request historic Property values and Relationships that were valid
within the specified timeframe.
The following grammar defines the syntax that shall be supported:
timerel = beforeRel / afterRel / betweenRel
beforeRel = "before"
afterRel = "after"
betweenRel = "between"
The points in time for comparison are defined as follows:
• A time element, which shall represent the comparison point for the before and after relation and the starting
point for the between relation. It shall be represented as DateTime (mandated by clause 4.6.3).
• An endtime element, which is only used for the between relation and shall represent the end point for
comparison. It shall be represented as DateTime (mandated by clause 4.6.3).
And in the "C.5.5 Temporal Query" there is query example
GET /ngsild/v1/*temporal*/entities/?type=Vehicle&q=brandName!=Mercedes&attrs=speed,brandName**&timerel=between
&time=2018-08-01:12:00:00Z&endTime=2018-08-01:13:00:00Z**
I'm trying to run similar GET request(Orion-LD (with Mintaka)) against certain data and get "400" back with: "time is unknown" (or "endTime is unknown" if I remove "time" condition from the string).
If I remove the part of the request that has timerel, time and endDate, then this GET request returns data fine. Therefore I was wondering if the part of the specification described in"4.11 NGSI-LD Temporal Query language". has been implemented in Orion_LD?
Thank you
Orion-LD does support the Temporal Interfaces of NGSI-LD, it just requires the component "Mintaka" for that: https://github.com/FIWARE/mintaka
Orion-LD needs to store the data in TimescaleDB, where it than can be retrieved via Mintaka. To enable the storage on timescale, see https://github.com/FIWARE/context.Orion-LD/blob/develop/doc/manuals-ld/troe.md
I have analysed several articles about naming conventions for Date/Time types in SQL data models.
Most of them suggest implementing a database design where a timestamp type is used for some registered even values only, literally timestamping the event case just when it happens. And naturally they suggest datetime type for any other time instanting needs. And they suggest to avoid using suffixes and prefixes which match known data types, like date and time, at all costs, to avoid confusion with data types where only the purpose of the column name is expected.
But PostgreSQL dialect does not have that datetime type at all, so there is only the timestamp type for all cases when just date and time are not enough for the column which is expected to store a value of past or future instant of time.
So, basically, what prefixes or suffixes if any would you suggest for PostgreSQL dialect columns, known that some of them would store past and present and future time instants? And why, for what benefits or because of what limitations?
Should we use timestamp and datetime as prefixes or suffixes to distinguish the purpose of different timestamp type columns by their names? Or would that be a bad practice since there is actually a data type named timestamp and no data type named datetime in PostgreSQL dialect?
Or should we maybe use something very neurtal like an instant noun as a prefix or suffix to denote the purpose of the column?
I have doubts about which is the best type for a field annotated with #Version for optimistic locking in JPA.
The API javadoc (http://docs.oracle.com/javaee/7/api/javax/persistence/Version.html) says:
"The following types are supported for version properties: int, Integer, short, Short, long, Long, java.sql.Timestamp."
In other page (http://en.wikibooks.org/wiki/Java_Persistence/Locking#Optimistic_Locking) says:
"JPA supports using an optimistic locking version field that gets updated on each update. The field can either be numeric or a timestamp value. A numeric value is recommended as a numeric value is more precise, portable, performant and easier to deal with than a timestamp."
"Timestamp locking is frequently used if the table already has a last updated timestamp column, and is also a convenient way to auto update a last updated column. The timestamp version value can be more useful than a numeric version, as it includes the relevant information on when the object was last updated."
The questions I have are:
Is better a Timestamp type if you are going to have a lastUpdated field or is better to have a numeric version field and the timestamp in other field?
Between numeric types (int, Integer, short, Short, long, Long) which is the best to choose (considering the length of each type)? I mean, I think the best is Long but it requires a lot of space for each row.
What happens when the version field gets to the last number of a numeric type (for example 32,767 in a Short field)? Will it start from 1 again in the next increment?
Just go with Long or Integer.
BUT don't go with int or long.
In opposite to other comment here, null value is expected when entity was never persisted yet.
Having int or long might make Hibernate to think that entity is already persisted and in detached state as version value will be 0 when unset.
Just finished debugging a FK violation where "int" was the cause, so save your time and just go with Long or Integer.
First, know that locking is used to managed concurrent transactions.
1.Separate your concerns. If lastupdated field is business model specific, it should be separate from your versioning field - which is for - versioning.
2.Primitives and objects are usually mapped to your db as the same type. Except for the fact that Boolean by default will be nullable and boolean will be 'not nullable'. However, enforce nullability explicitly. In this case you want to use a primitive as the version field can't be nullable.
Integer or long are better than timestamp. Hibernate recommends numeric versionig and they don't take that much space.
If you use long, you might not live to find out.
Use this and you should be fine.
private long version;
#Version
public long getVersion() {
return version;
}
public void setVersion(long version) {
this.version = version;
}
Don't use a time value like Timestamp (or derivates like Instant or LocalDateTime etc...).
Especially if you have a Java < 15 application and hope to ever migrate to Java >= 15. They changed the precision of timestamps within Java to nano-seconds, but your database probably only stores up to microseconds, so it truncates the value, which will make you run into an OptimisticLockException all the time (1).
Neither use a primitive value, see the answer from #Piotr: The Version field must be null for new entities.
Just go with Long.
I have a core data entity that has a created_at attribute which is a NSDate, and an amount attribute which is a NSInteger.
I would like to make a request that returns the sum of amounts grouped by months. Something like:
[['February 2010', 450], ['January 2010', 300]]
I'm not sure how to approach this, if I would have to first fetch all results for a specific date range, and then calculate sum, or if there are other methods.
P.S. I'm doing this on the iphone 4.2 sdk.
Even thought an answer has already be accepted let me add this more sophisticated and faster method for completeness.
Assuming the months aren't modeled in your data model, you will need to fetch the objects in each month and then sum the amounts. Repeat for as many months as you need.
So, the first step is to create a variable predicate for the fetch. Something like this:
NSPredicate *exPred=[NSPredicate predicateWithFormat:#"%#<=created_at<=%#", monthStartDate,monthEndDate];
NSPredicate *exPred=[NSPredicate predicateWithFormat:#"(%#<=created_at) AND (created_at<=%#)", monthStartDate,monthEndDate];
... then execute the fetch and sum the return:
NSNumber *theSum=[#sum.[context executeFetchRequest:theFetch error:&error].amount];
... or less cowboy:
NSArray *fetchedObjects=[context executeFetchRequest:theFetch error:&error];
// if no error
NSNumber *theSum=[fetchedObjects valueForKeyPath:#"#sum.amount"];
Put that in a loop for each month.
Predicates and collection operates are much faster than loops. Use them instead of loops whenever possible.
I'd fetch the range of objects you're interested into an array, then enumerate through that array and add all the amounts up on the go.
I'm not sure if this could be solved by creating a sophisticated request too, but my gut feeling tells me it would be tricky to set up anyway (if possible at all)...
Is it possible to see the completed query string, with all the variables substituted to their actual values? Would be good for debugging...
You could just log the predicate with NSLog(#"%#", predicate). Most values will show directly, except those that are cast e.g. dates or bool. For those you will have to log the variable separately.
Yes, turn on Core Data debug and you will see the raw sql calls.
http://developer.apple.com/mac/library/documentation/cocoa/conceptual/CoreData/Articles/cdTroubleshooting.html