Reading document, I saw there are four types of uuid. I am wondering how to generate type 1(timestamp based) and type2 (DCE security based) uuid. Any idea?
You can also implement your own if for whatever reason you don't want to use JUG (as suggested above).
For this check the class UUID. You need to use System.nanoTime() and ensure successive calls return increasing values (so if you get two times the same time value, then return the greatest returned value so far plus 1).
The layout of the UUID type 1 can be found in: http://www.ietf.org/rfc/rfc4122.txt
Related
I have been using two codes below when i'm trying to find record by email or phone number, sometimes first code working fine sometimes not working and also the second code same too.
what is the difference between codes below and when i should use "equalTo" or "startAt and endAt"?
ref.orderByChild("email")
.equalTo(str)
and
ref.orderByChild("email")
.startAt(str)
.endAt(str+"\\uf8ff")
ref.orderByChild("email").equalTo(str)
The above means that the email has to be equal to the value of str. It is the same as saying WHERE email= 'userx#gmail.com'
ref.orderByChild("email").startAt(str).endAt(str+"\\uf8ff")
This is like saying WHERE email LIKE ca% which will return all emails that start with "ca"
public Query startAt (String value)
Create a query constrained to only return child nodes with a value greater than or equal to the given value, using the given orderBy directive or priority as default.
public Query endAt (String value)
Create a query constrained to only return child nodes with a value less than or equal to the given value, using the given orderBy directive or priority as default.
The \uf8ff is simply the last character in unicode, so acts as an end guard.
Check this for queries:
https://www.youtube.com/watch?v=sKFLI5FOOHs
It's true that in "some" cases, you can achieve the same thing using either the first approach or either the other but from the official documentation regarding filtering data, each method has a difference purpose as:
equalTo() - Return items equal to the specified key or value depending on the order-by method chosen.
startAt() - Return items greater than or equal to the specified key or value depending on the order-by method chosen.
endAt() - Return items less than or equal to the specified key or value depending on the order-by method chosen.
But as a conclusion, use the first approach when you want to have a perfect match. The second approach is used usually for a search query when you want to filter data that starts with some characters. In terms of SQL, note that there isn't an equivalent to LIKE clause in Firebase but with the second approach we simulate the exact same behaviour.
How to get sequence number for WT.Part or Wt.Document in Windchill through API?
When I create WT.Part - number automatically generated. But I can not find any method that returns the next number. I'm using Info*Engine.
At the time of object WTPart creation windchill use OOTB oracle_seqence in order to auto generate the number.
The sequence name is mentioned in the OIR of respective object.
Like
For
WTPart it is : WTPARTID_seq
For
WTDocument it is : WTDOCUMENTID_seq
etc .
So, if you want to get next number of WTPart then you can directly call the method wt.fc.PersistenceHelper.manager.getNextSequence("WTPARTID_seq");
from your info*engine task.
For different object the name of the sequence will be different.
In 10.2 PTC introduce another method getCurrentSequence("SEQ_NAME") to get the current sequence value without incrementing the same.
Are you familar with using Java with InfoEngine? If so, you can get the sequence by:
wt.fc.PersistenceHelper.manager.getNextSequence("SEQUENCE_NUMBER_OF_YOUR_OBJECT")
The sequence number will be specified inside the "Object Initialization Rule" that is associated with your object type.
As a temporary solution - create a new Part, read the number and either use it or delete.
I am using Hibernate and Criteria API to write my database quires. What I need to do is I need two dates difference in days and compare that days with with specific number.
E.g. Commonly written criteria restriction as:
criteria.add(Restrictions.eq("somProperty", someValue));
What I needs is:
criteria.add(Restrictions.ge("dateProperty1 - dateProperty2", 15));
Means date difference between two dates is greater than or equal 15 days.
I don't see how to achieve this. And yes I did lots of Google to find out the possible solution but didn't get proper material what I need.
If you check the documentation of the Restrictions class, you will see that:
most functions operate on a "property vs value" pair (just like in your first example)
the remaining comparator functions operate on "property vs other property" pair
But no customized function is available for your case. So what option you have is using the sqlRestriction, which can be used to express this condition in a native form of your DBMS. That would be a different, but much easier problem, altough clearly not as elegant as your original idea.
I have an integer field in the DB (Postgresql) and my hibernate mapping file that I want to use in a like operation (e.g. Restrictions.like(Bean.fieldname,'123')).
The database does not support like for integer without explicit type casting select * from table where text(myint) like '1%'. Ideally, I'd like to keep the DB field type and Hibernate property type as integers and not have to load all the fields from the DB to iterate through in the Java code.
cheers :)
If the value really is a number, I'd just restrict it to a range - e.g. greater than or equal to 100 and less than 200. I wouldn't have thought you'd really want "all numbers starting with 1" - that suggests that 1 and 10000 are similar, whereas 1 and 2 are totally different. The information in a number should almost always relate to its magnitude, not the digits from its decimal representation.
Why do you need a LIKE? It's a very strange comparison, that's also why it's not an integer operator.
You could cast the value in the database to text/varchar, but you will kill performance unless you create a special index as well.
Restrictions.sqlRestriction("CAST({alias}.myint AS CHAR) like ?", "%1%", Hibernate.STRING));
what is the best solution in terms of performance and "readability/good coding style" to represent a (Java) Enumeration (fixed set of constants) on the DB layer in regard to an integer (or any number datatype in general) vs a string representation.
Caveat: There are some database systems that support "Enums" directly but this would require to keept the Database Enum-Definition in sync with the Business-Layer-implementation. Furthermore this kind of datatype might not be available on all Database systems and as well might differ in the syntax => I am looking for an easy solution that is easy to mange and available on all database systems. (So my question only adresses the Number vs String representation.)
The Number representation of a constants seems to me very efficient to store (for example consumes only two bytes as integer) and is most likely very fast in terms of indexing, but hard to read ("0" vs. "1" etc)..
The String representation is more readable (storing "enabled" and "disabled" compared to a "0" and "1" ), but consumes much mor storage space and is most likely also slower in regard to indexing.
My questions is, did I miss some important aspects? What would you suggest to use for an enum representation on the Database layer.
Thank you very much!
In most cases, I prefer to use a short alphanumeric code, and then have a lookup table with the expanded text. When necessary I build the enum table in the program dynamically from the database table.
For example, suppose we have a field that is supposed to contain, say, transaction type, and the possible values are Sale, Return, Service, and Layaway. I'd create a transaction type table with code and description, make the codes maybe "SA", "RE", "SV", and "LY", and use the code field as the primary key. Then in each transaction record I'd post that code. This takes less space than an integer key in the record itself and in the index. Exactly how it is processed depends on the database engine but it shouldn't be dramatically less efficient than an integer key. And because it's mnemonic it's very easy to use. You can dump a record and easily see what the values are and likely remember which is which. You can display the codes without translation in user output and the users can make sense of them. Indeed, this can give you a performance gain over integer keys: In many cases the abbreviation is good for the users -- they often want abbreviations to keep displays compact and avoid scrolling -- so you don't need to join on the transaction table to get a translation.
I would definitely NOT store a long text value in every record. Like in this example, I would not want to dispense with the transaction table and store "Layaway". Not only is this inefficient, but it is quite possible that someday the users will say that they want it changed to "Layaway sale", or even some subtle difference like "Lay-away". Then you not only have to update every record in the database, but you have to search through the program for every place this text occurs and change it. Also, the longer the text, the more likely that somewhere along the line a programmer will mis-spell it and create obscure bugs.
Also, having a transaction type table provides a convenient place to store additional information about the transaction type. Never ever ever write code that says "if whatevercode='A' or whatevercode='C' or whatevercode='X' then ..." Whatever it is that makes those three codes somehow different from all other codes, put a field for it in the transaction table and test that field. If you say, "Well, those are all the tax-related codes" or whatever, then fine, create a field called "tax_related" and set it to true or false for each code value as appropriate. Otherwise when someone creates a new transaction type, they have to look through all those if/or lists and figure out which ones this type should be added to and which it shouldn't. I've read plenty of baffling programs where I had to figure out why some logic applied to these three code values but not others, and when you think a fourth value ought to be included in the list, it's very hard to tell whether it is missing because it is really different in some way, or if the programmer made a mistake.
The only type I don't create the translation table is when the list is very short, there is no additional data to keep, and it is clear from the nature of the universe that it is unlikely to ever change so the values can be safely hard-coded. Like true/false or positive/negative/zero or male/female. (And hey, even that last one, obvious as it seems, there are people insisting we now include "transgendered" and the like.)
Some people dogmatically insist that every table have an auto-generated sequential integer key. Such keys are an excellent choice in many cases, but for code lists, I prefer the short alpha key for the reasons stated above.
I would store the string representation, as this is easy to correlate back to the enum and much more stable. Using ordinal() would be bad because it can change if you add a new enum to the middle of the series, so you would have to implement your own numbering system.
In terms of performance, it all depends on what the enums would be used for, but it is most likely a premature optimization to develop a whole separate representation with conversion rather than just use the natural String representation.