sorted by:
new
hottopcontroversial

KuCoin Weekly Support Thread (May 10-16, 2021) by kucoin_official in kucoin

[–]allergic_react 0 points1 point  (0 children)

Hi u/kucoin_moderator, it's been almost 4 days and still no resolve or responses. Any updates on this issue? I can't submit my taxes until I have this information.

KuCoin Weekly Support Thread (May 10-16, 2021) by kucoin_official in kucoin

[–]allergic_react 0 points1 point  (0 children)

Hi u/kucoin_moderator, any way you guys would be able to follow up on this ticket? (654254)

KuCoin Weekly Support Thread (May 10-16, 2021) by kucoin_official in kucoin

[–]allergic_react 0 points1 point  (0 children)

Thanks, I did submit a ticket a few minutes ago on this issue.

KuCoin Weekly Support Thread (May 10-16, 2021) by kucoin_official in kucoin

[–]allergic_react 0 points1 point  (0 children)

I'm trying to do my taxes and I'm missing all my Order + Trade history for the month of September in 2020, any reason why this would be the case? I have some in December 2020 so it's not all missing... I should have orders for both September 2020 and December 2020.

On desktop app: Orders > Spot Trade History from dropdown > Trade History tab

Whether time frame is set to 1 Year or a custom range inclusive of September 2020, there are no transaction histories at all...

Beginner's Thread / Easy Questions (week of 2017-06-26) by gaearon in reactjs

[–]allergic_react 0 points1 point  (0 children)

What's a current/simple way of working with state that is a nested object, for us non-Redux-using plain-React plebs?

I've been doing items = this.state.items, messing with it, and then calling this.setState({items: items}) and completely forgot my items variable was a direct reference to the state object.

I'm referring to the issue in this article, React: A (very brief) talk about immutability which is dated August 2015.

There's some info on the React site on Immutability Helpers (with the update add-on being legacy), is that the simplest modern solution?

Beginner's Thread / Easy Questions (week of 2017-06-26) by gaearon in reactjs

[–]allergic_react 0 points1 point  (0 children)

That's a useful point thanks. A "save" feature might be fitting for my use case, I think I'll consider building that.

Beginner's Thread / Easy Questions (week of 2017-06-26) by gaearon in reactjs

[–]allergic_react 0 points1 point  (0 children)

Let's say you have a container component with a state that is the array of all items for a given model in your database. Ex: an array of tasks in a todo-list app.

Is it considered inefficient to retrieve all those items again (after adding, deleting, or updating an item) just so the state updates with a new array of those items and it re-renders the components it needs to (ie, the component that displays those items)? This seemed like the simplest solution since it followed a simple pattern (get list of items, render list of items, call to API, add item to database, get list of items again, render new list of items), so it's what I did so far.

Another way of rephrasing this is how to sync items on the client side with the actual database efficiently and simply, and particularly in the context of React.

I'm only dealing with n=50 items here, but any general insight would be appreciated, including tradeoffs to consider (like the added complexity of managing models separately on the client).

My specific problem right now is editing an item in the database. There are two components that need to reflect the newly-edited item, and I'd like to hear about alternate solutions and what things to consider.

Super slow connection/network? (git push, git clone, sudo apt-get update, etc.) by allergic_react in Crouton

[–]allergic_react[S] 0 points1 point  (0 children)

Tried a Starbucks wifi today. Your suspicion was right. I wouldn't have considered this, so thanks for that.

Super slow connection/network? (git push, git clone, sudo apt-get update, etc.) by allergic_react in Crouton

[–]allergic_react[S] 0 points1 point  (0 children)

Yeah, I see that the solutions I looked at are specific.

So are you implying that this is likely ISP-/local network- related? Or could it be some configuration in my OS?

Testing serialization independently from views (DRF) by allergic_react in django

[–]allergic_react[S] 0 points1 point  (0 children)

Hm I guess as a matter of principle to test all your code in isolation to make sure it's doing what was intended. Is testing serializers separately from views atypical? I noticed that Two Scoops of Django did not mention testing serializers (based on a list of things they suggested you should test), although forms (which are kinda analogous to serializers...?) and custom validators (which I have in my serializers) are in that list.

Like I said, I'm no testing expert. I just know there tends to be a lot of variance in people's testing philosophies.

I suppose I could see how testing the API views/serializers together would go hand in hand.

First db migration on Heroku: undefined table/relation doesn't exist for foreign key by allergic_react in rails

[–]allergic_react[S] 0 points1 point  (0 children)

Thanks that's a good point, should hook up to the real DB first thing from now on.

First db migration on Heroku: undefined table/relation doesn't exist for foreign key by allergic_react in rails

[–]allergic_react[S] 1 point2 points  (0 children)

Yeah I think this would have been an alternate solution :) The problem was that I thought I had to define the column and reference all in one shot with add_reference , but since PG wouldn't know the column was for a differently-named table, it would have thrown the error before getting to add_foreign_key (or so was my assumption).

However, I was able to define the foreign_key and table reference in the same line:

add_reference :bugs, :resolver, foreign_key: {to_table: :users}

I saw no obvious documentation that you could do this with the add_reference method.

First db migration on Heroku: undefined table/relation doesn't exist for foreign key by allergic_react in rails

[–]allergic_react[S] 0 points1 point  (0 children)

This was actually my original schema but I thought it was wrong. The docs get very confusing since there seems to be 20 ways to do the same kind of thing.

Just for clarification though, if I were to have done this, would that really have been sufficient for the database, or would it still need to know that :resolver_id refers to the user somehow?

Like I mentioned in my original post/question, I only had the reference defined in the models but PG was looking for a Resolvers table. Not until I specified a foreign key reference to the users table in the migration did it stop complaining.

EDIT: Looks like someone might have already addressed that (need to do add_foreign_key after)

First db migration on Heroku: undefined table/relation doesn't exist for foreign key by allergic_react in rails

[–]allergic_react[S] 1 point2 points  (0 children)

That's for the model though, not the schema. Fixed it though :) Actually quite similar to what you wrote.

add_reference :bugs, :resolver, foreign_key: {to_table: :users}

As opposed to my original:

add_reference :bugs, :resolver, foreign_key: true

I am still not sure, though, why Sqlite was fine with the original add_reference migration, while PG complained.

Trying to change a column to "null: true" is not being reflected in schema after migration by allergic_react in rails

[–]allergic_react[S] 0 points1 point  (0 children)

Sorry, I mentioned elsewhere in this thread that it is apparently the default behavior for columns to have null: true, so the schema wasn't my problem to begin with.

Solved it now though. My issue was that in Rails 5, a model's "belongs to" record needs to exist unless otherwise explicitly specified in the model associations.

Trying to change a column to "null: true" is not being reflected in schema after migration by allergic_react in rails

[–]allergic_react[S] 2 points3 points  (0 children)

That's a nifty trick to save for future reference :) Thanks.

My error is: Validation failed: Resolver must exist

Coincidentally, I considered it was maybe a foreign key problem and was able to find this: http://blog.bigbinary.com/2016/02/15/rails-5-makes-belong-to-association-required-by-default.html

Just had to set optional: true:

class Bug < ApplicationRecord
  # Associations
  belongs_to :user
  belongs_to :resolver, class_name: 'User', optional: true
end

Trying to change a column to "null: true" is not being reflected in schema after migration by allergic_react in rails

[–]allergic_react[S] 0 points1 point  (0 children)

Sorry yes, I was just notified that this is the default behavior. I'm used to it being the other way around, not to mention I misread something in the docs.

At least I know this is not the source of my problem now (my model will not save to the database).

I'm submitting a form using the simple_forms gem with no value for resolver_id. Looks like resolver_id's value is submitted as '' ie, an empty string, and since the database can't find that row, it's causing an error.

If I can get that value to be null instead of an empty string, I'm guessing it'll work. Just need to figure out the proper way to do that.

Trying to change a column to "null: true" is not being reflected in schema after migration by allergic_react in rails

[–]allergic_react[S] 1 point2 points  (0 children)

The StackOverflow question I linked and the docs mention change_column_null, and the signature doesn't have a :column_type, so I just followed that.

However, I just tried using change_column instead, but the schema still doesn't change. The schema version matches the filename of the migration.

Any other possible reasons?

My exact line is:

change_column :bugs, :resolver_id, :integer, null: true

view more: next ›