It's a bit stupid question, but I don't have enough relevant expirience to answer it myself.
Can a snowflake generated ID (274950720577339394), be bigger then unsigned_long type of integer? (2^64-1)
Just a bit more info. I'd like to store snowflake IDs inside the elasticsearch index, and according to it's integer types there is a unsigned_long which I guess should perfectly fit, and store snowflake as a number. So doesn't it a good idea? Or it's safe to use keyword instead of int types?
No, they can't.
According to this post on Google Groups,
IDs will still be 64-bit unsigned integers
Note that this post was posted in 2010, which is a while ago, but it doesn't seem it was changed.
Related
Apologies if this has come up before, but I couldn't find anything.
I am using GraphCMS (highly recommend it) and I have several fields that are floats. I am using them for prices. Each entry in the schema can either be a buy or sell in an enumeration field. I would like to total all the price fields where the entry is a buy, and total all the price fields where the entry is a sell.
I thought there would be something clear in the docs because totalling those fields would be very useful for something like calculating an average score etc. but I can only see docs about counting entries. Have I missed it somewhere?
Surely this is possible?
After speaking with the helpful guys at GraphCMS I have figured out how to do it. This is not a question about GraphCMS as #puelo suggested, but can be achieved by running a graphql query and then programatically running calculations with the data. It's a simple solution but wasn't immediately apparent to me at first. Hopefully that info will be useful to other newbies.
For a certain program I have some type-keywords values like this:
Program Type Keyword
PIM Kind Additional
PIM Period Education
PIM Phase Specialized
PIM Skills Professional
The type is a fixed value, but the keyword depends of the Program and type. I want to transpose this result in analytics by making 4 columns with the type. The result has to look like this:
Program Kind period phase skills
PIM Additional Education Specialized Professional
I have tried by editing the column formula and putting this formula:
CASE WHEN "Type"='Partial period' THEN "Keyword" END
and so on for each different type. But it doesn't give me the result I want. all the new columns are empty.
I also tried with a pivot table, but the keyword isn't a measure, so I don't think this will work.
can someone help?
This simply doesn't make sense in an analytical way. You have no fact, nothing you measure. So no chance of using FILTER...USING... for example.
Don't forget you're not in Excel or a drawing tool. You're in an analytics tool which tries to make sense out of data and not "show data in a weird way".
You have to model things nicely either in the data source itself or be clever in the construction of your RPD.
It's doable in the RPD but it will be quite static and if the list of values changes you will have to adapt it.
tl;dr - garbage data, garbage result
So, a company I work at has an older ERP system that uses FoxPro 4 or 5. There is no support for the system, so I am trying to use skills that I don't possess. I'm good with Servers and even networks, but not coding. I have attached links to two similar errors that are occuring to two different users in different departments using different computers. Your help would be appreciated.
FoxPro Error 1
FoxPro Error 2
Well, the problem is exactly what it says on the tin. It looks like the issue is with the field BODY.COST. The field will have a maximum capacity, for example N(12, 2) would allow numbers up to 999999999.99 to be stored in it.
The system is attempting to put a number that is bigger than the defined capacity into this field. You can see it is a GATHER MEMVAR statement in both cases. This statement takes memory variables and updates a database table using them. One of the memory variables has ended up with a bigger number in it than the database field (looks like BODY.COST) that is intended to store it has capacity for.
Beyond that, with no support and no source code you are really limited to looking at what the user is trying to post and seeing if that gives you any clues. Is that the extent of the error dumps or are those just snippets?
The messages are saying that you are trying to store a larger value than the field would accept. This happens with numeric and float fields in Foxpro. In both of the messages, the table was indirectly aliased as "BODY" and the problematic field is "COST".
As a solution, using VFP5 (do not use a later version - there weren't VFP4), you can make all the numeric and float fields to either Currency or Double data type.
Currency has a high certainity and suggested for monetary values (need not be monetary). It is in the range of –922337203685477.5808 to 922337203685477.5807. That range is actually above what a numeric/float field can support.
If you think that is not enough range, than you can use double (something like -10^327 to 10^304 - VFP has a precision of 15 digits, you lose precision beyond that).
I would go with Currency.
Just want to know what are the corresponding datatype that I should declare when using DataMapper.
Types in MySQL
smallint
bit
varchar
Can anyone tell me the corresponding type in DataMapper?
Thanks.
According to this site you are fairly limited with no specific equivalents. Varchar somewhat equals string and integer seems to take the place of bigint. Bit is not mentioned at all. The idea is born out further by this link (click on show source) where you will see the adapter for MySQL maps the data types similar to above. Again, bit is not mentioned.
I am building an application with a many to many relationship;
An item of entity 'Picture' can be linked to any number of Galleries ('Gallery'). And of course a Gallery can hold any number of Pictures.
So, following the Google Suggestion here, I will use a List at 'Picture' which holds the foreign keys of 'Gallery'. This is the BigTable approach.
(The old-style Relational DB approach would be to have a table / entity in between 'Picture' and 'Gallery'.)
Here's my question: When storing the Key, should I go for a "StringListProperty" on 'Picture' or would a "ListProperty(db.Key)" work better?
One reason I see for a StringList would be, that I could store also other values then Keys, but on the other hand that would be dirty style anyway. But I am also pretty sure that Google suggested not to use more then one List at an entity because the Index(es) will explode. So this will keep me a backdoor.
As for the ListProperty with type "Key" one point would be the automatic verification, if the value is actually a Key.
As it is very easy to convert Strings to Keys and vice versa, I don't see any reason for one of the List types to prefer here.
When it comes to performance issues, I have no idea on how I could test this - but it looks like this will be the main factor in this decision.
Curious about your input. Especially if someone has tested the performance on this or would be so kind and do it.
Cheers,
//Hannes
Use a db.ListProperty(db.Key) if you're intending to store lists of keys. They will be stored in a binary representation, which is more compact than the string representation you would use in a string list.
You're right that mixing keys with other objects in a list is messy. Having multiple lists in an entity is fine, as long as you don't index more than one of them in the same custom index - that is what causes exploding indexes.
Use db.ListProperty(db.Key), this is will make the data fetch easier than string.. if Gallery model has property had pic_list which is of type db.ListProperty(db.Key), which contains the list of keys of picture entity.. Suppose Picture is the name of your entity.. then Picture.get(//GalleryObject//.pic_list) will get all the picture entites..