Needs sync_to_async in async context

Describe the problem
When used in an async view, you need to access the object with a sync_to_async wrapper or this error will get raised:
SynchronousOnlyOperation: You cannot call this from an async context - use a thread or sync_to_async
Steps to reproduce
Create an async view in Django 3.1 and try to access an attribute of the config object.
System configuration

Django version: 3.1
Python version: 3.9
Django-Constance version: 2.8.0

I came here to report something similar. This error also occurs if trying to use constance settings in views.py or urls.py (anything that gets called when Django starts up) when using the latest django-channels and deploying the app with asgi. An example would be using a constance config as a constant in a caching decorator.

Same - django 3.1, python 3.7, latest constance

Any thoughts?
More details:

py 3.7, django 3.1, daphne 3.0.1, asgref 3.2.10, constance 2.8.0 (latest), no channels
constance via postgres/redis
triggering scenario is urls.py calls config.XYZ as part of import

More complete workaround:
from asgiref.sync import sync_to_async
from constance import config

@sync_to_async
def safe_constance_get(fld: str):
    return getattr(config, fld)

z = safe_constance_get('Z')

mea culpa, not always the right fix: can get you a <coroutine obj> that'll need to be run
This is a common use case so not sure

https://channels.readthedocs.io/en/stable/topics/databases.html#database-sync-to-async is recommended way to wrap. What changes do you expect in django-constance?

@sergei-iurchenko Hi! Thanks for answering. Considering that the Constance API is as simple as Django's Settings API, It would've been better if the library handled the synchronous context to reduce the confusion for a beginning user. Doing this would also prevent the code from being coupled to the storage backend (Because you won't need to use sync_to_async when using a Redis backend.

I see your point.
How do you see expected changed to support it?
I just do not see any obvious way to implement this.


Migrate to Hugo

Since the currently used Static Site Generator (mixture.io) has been discontinued long ago, we have to switch to another generator. We plan to migrate to Hugo. It's not a trivial task with all the languages and complex structure of tutorials and tutorial parts.

The URL of the following text needs to be updated:
What's Next?
In Tutorial Part 3 we will add more functionality like adding, deleting and editing Persons.
Present URL: /library/javafx-8-tutorial/part3
Correct URL: javafx-8-tutorial-en-part3.md


[Bug]: dont save quest (bug with Ä Ü Ö)

Bug Description
we need a save botton after change/edit a Quest (text/reward) he don´t save this.
next problem is, i think it is Ä Ü Ö bug in Overview and remove my progress (my problem is i come from germany Ä Ü Ö are in many words and i forgot to change ist to.) Change to: Ä =Ae | Ö =Oe | Ü = Ue.
Pls help me i like your Mod so much i want to make quest without problems but after 30 Quest he delete 20 Quest and 3 houre progress is done.
How to Reproduce?
Add a Quest
After give the Quest A name with Ä Ü Ö
or in Overview Text is Ä Ü Ö
or in Subtitle is Ä Ü Ö
i think this is the Problem
Expected Behavior
No response
Version
0.0.5 and 0.0.6
Mod Loader Version
1.20.1 - 47.1.39
Mod Loader
Forge
Logs or additional context
No response
Code of Conduct

[x] I have searched the issue tracker and confirmed that the issue has not been reported
[x] I have checked the FAQ (if one is present) and my issue is not listed
[x] I have verified that I am using the latest version of the mod
[x] I have verified that I have installed all the required dependencies for the mod
[X] I have verified that I do not have Optifine installed. We will close issues if we detect Optifine is in your pack. We cannot fix Optifine issues. Please do not report issues with Optifine present.

Things are automatically saved, a save button would not do anything.

I cant reproduce any issues with those characters in titles, subtitles, or overviews it works perfectly fine for me.

I cant reproduce any issues with those characters in titles, subtitles, or overviews it works perfectly fine for me.

I'm having the same issue with the quest not saving the data, I have been messing around with it and found out that after the 3rd quest and you try to link the quest up and change the icon background and icon close out of the menu and reopen it, it does not save the changes. This is also with the mod that you gave me.

So we dont have 2 reports with similar reportings I am closing this in favor of #45


Missing Instructions for pod install in Contributing Guide

The contributing guide for the react-native-omh-auth repository is missing a crucial step for running pod install after setting up the project. This omission can lead to build failures when running yarn start or yarn workspace react-native-omh-auth-sample ios.
Steps to Reproduce:

Clone the react-native-omh-auth repository.
Follow the setup instructions in the contributing guide.
Run yarn start or yarn workspace react-native-omh-auth-sample ios.

Actual Result:
The build fails with errors such as:
error: unable to open configuration settings file
warning: Unable to read contents of XCFileList
error: Unable to load contents of file list

Possible Solution:
For newcomers, this step might be easy to miss but is essential for the build process. Add the following step to the contributing guide after running yarn install:

Navigate to the ios directory:cd apps/sample-app/ios

Run pod install to install the required CocoaPods dependencies:pod install

Continue with:yarn start

oryarn workspace react-native-omh-auth-sample ios

Note (optional in contributing.md):
Ensure CocoaPods is installed. If you encounter zsh: command not found: pod, install CocoaPods using:
sudo gem install cocoapods

Adding these instructions will prevent build errors due to missing CocoaPods dependencies and improve the onboarding experience for new contributors.
Thank you!
CC - @artus9033 in case this is also needed for maps.

LGTM. Thanks, Andrei.


⚠ Bofrost.lu has degraded performance

In 05a4231, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 864 ms

Resolved: Bofrost.lu performance has improved in d2790d4 after 9 minutes.


Shift + space is not working correctly in Oni

There's a bug in our input handling - when the user presses Shift + Space, we should be sending <s- > to Neovim, but we are just sending the space character  . Note that the control key works correctly, sending <c- >.

You can repro this via nnoremap <s-space> :echo 'test'<CR> in Oni, and pressing shift + space


Turn isna() and notna() into TypeGuards

[X] Tests added: Please use assert_type() to assert the type of any return value

Putting up a draft first because I actually am not quite sure what the best way to go about this is. I wrote the tests first, as to what the behavior intuitively should be, but getting the annotations to match is the challenging part.
Further, I'm still not perfectly happy with these annotations, because I have seen tons of code use pd.isnull on any random object, and the annotations currently do not support this, they only really allow pandas objects and a curated list of Scalar objects.

Closing this for now, until TypeGuard is compatible with overloads, this is not viable.

Reopening

TODO: One, I probably will have to just silence the conflicting test by commenting it out / removing it. That said, MyPy and Pyright ought to have the same behavior, so I'll bring it up on Pyright's forums first. Given that I suspect Pyright is right here, may end up posting it as a Mypy issue. In any case, whichever type checker is wrong, probably isn't going to get fixed any soon, hence why I will silence it.

So I ended up commenting out the tests that had conflicting behavior. In summary:

The current spec of TypeGuard does not enable as precise type narrowing as would be ideal. This is unlikely to be remedied anytime soon, I'd imagine this is something a PEP would be required to enable.
I took the step of annotating as a comment what the correct/optimal type assertion should be. These remain commented solely for documentation for now, although if and when in the future they become viable, they can be used as actual assertions.
There are also certain cases in which MyPy and Pyright produce conflicting behavior. These have likewise been commented out for documentation purposes. If, in the future, the two type checkers converge to the same behavior, we may want to enable these assertions.

So I upgraded to the latest version in conda today. It's definitely an improvement as this uncovered a new legitimate type error in my code base. Unfortunately, it's not perfect due to the lack of strict type narrowing semantics, as well as lack of type narrowing in the negative case. I hope StrictTypeGuard gains some traction to improve this.


🔧 Repository: Make backstage/community-plugins workflows more easily repeatable (with tooling)

Some Backstage plugin developers I have spoken to have mentioned they'd a setup like backstage/community-plugins for their internal plugin development. I've also heard some are already using this structure as inspiration for their initial workflows.
This issue is to propose making community plugins tooling more consumable and repeatable for plugin developers.
For now, it is possible to reuse the workflows in the repository, however, I believe they're not as consumable as they could be. Some possible enhancements/ideas I've thought of:

Identifying/isolating 'mandatory/required' workflows from additional workflows (such as Renovate, PR sync, etc.)
Documentation on what GitHub/npm/user accounts are required by the workflows.
Make @backstage-community/repo-tools end-user facing, perhaps publishing as a package.
Some mechanism to keep workflows up-to-date.
Some tooling like npx @backstage-community/repo-tools create-repository to generate the mandatory/needed workflows and structure.

This is something I believe would be pretty valuable, and create a common default pattern for plugin development.
Are you willing to submit PR?
Yes I am willing to submit a PR!

We should probably keep this in mind while refactoring workflows, WDYT @BethGriggs @vinzscam ?


French language translations of title template, headings, labels, etc

Summary
Add French translations of title template, headings, labels, etc for locale code fr.
Potential Contributors
Only the StatConfig.py needs to be modified to implement this. Look for a comment block that has a list of steps necessary to contribute a locale.
Please target the dev branch with your PR.

Hello ! I can translate to french if you want @cicirello !
I see your GitHub Actions from this post on DEV

Thanks @thomasbnt. That will be great.

I start to contribute on October for Hacktoberfest event 💪🏼☕


DRILL-4382: Remove dependency on drill-logical from vector package

@StevenMPhillips, can you please provide a narrative overview of the nature of these changes?

There are two main changes made in this commit:

Removed SchemaPath from MaterializedField. Now, a MaterializedField contains a name (String), and a list of children (MaterializedField). Each MaterializedField instance knows its own name, but has no knowledge of its parents. While making this change, I also got rid of MaterializedField.Key, and made sure that MaterializedField was not used as a Map key anywhere in the code.

TransferPair no longer takes a FieldReference, but instead will take a String for the field name.

With those two changes, I was able to remove the dependency on drill-logical.
The rest of the changes in the patch are simply making the rest of the code conform to this new interface.
I should not that this will break external StoragePlugins. They will need to be modified and recompiled.

Changes look good to me.  +1


Fixed crash if color picker left open when control is deallocated.

For example when switching to another view.  The color picker is now
automatically closed, which is a better experience, and avoids the
crash.

Removing the notification observer is correct, but we should only reset the panel's target if panel.target == nil. Someone might have changed the target of the shared panel.

There's no getter for the target property, so there's no way to check its value.  Elsewhere in the code sets it to nil.  Though it's weak linked, so probably don't actually need to reset it.

Actually, not sure about the weak linking.

Oops, it really only is a setter without a getter. How strange. I seems to be weak, just ran a quick test and it didn't increase the retain count of my object (it if weren't, dealloc of DFColorWell wouldn't be called, would it?)

Strange indeed.  I agree that it seems to be weak, so I've removed those two lines.  Thanks for the feedback.

Hmmm mouse events don't work inside the table view. Would making the table view the first responder solve this problem?

Other mouse events work if you set the highlight mode to None.  But the -mouseDown: doesn't work, hence my workaround.

Isn't this already solved by merging #10? Or is there something that still needs to be fixed?

I will take a look. There are merge conflict.

Sorry, did I accidentally trigger a pull request?  I was fixing an issue on my fork of the project: sending the action when setting the default color was overriding my app's settings on High Sierra. See my branch for my changes.


(Automatic) refresh functionality on the MelodyModel

In conversations with users, I found that it is partially unclear that the MelodyModel has to be reloaded if there are changes to the model. For example, if the Git model on the remote changes, users expected that this will also be adopted locally in an existing loaded model.
Therefore, I would suggest that we introduce an automatic reload flag in the MelodyModel, which states that the model is, for example, to be loaded from the source every minute.
An alternative would be a function model.reload() in the MelodyModel Class so that the model can be updated.
However, I cannot assess the complexity, I'm not sure in the two points:

What happens to local changes that have not yet been saved when a new loading happens?
Are all the information that are required to reload a model still there after the initial loading?

An alternative would be a function model.reload()

Auto-reload and model.reload() aren't mutually exclusive :)

to be loaded from the source every minute

This would need to be deferred to the FileHandler, because it knows the best way to get notified of updates (and can prefer, for example, inotify over constant polling).

What happens to local changes that have not yet been saved when a new loading happens?

Unless we implement some (potentially very complicated) automagic XML merge routine, unsaved changes will be lost. Which leads us immediately to the next point of pain: Due to our current architecture, we don't have any reliable way to track changes that were made to the XML tree – so we can't even warn users that this is about to happen, or make the auto-reload dependent on the "modified" state.
Another issue can arise when a model gets hot-reloaded while there are still living objects from it around (i.e. instances of GenericElement). These keep a reference to the LXML object, which in turn references back to the entire XML tree. In the best case, we "only" have a huge model loaded twice due to some forgotten references somewhere. In a significantly worse, but equally realistic case, these references are still used and access / modify the old, no longer used XML tree, which would lead to data loss.

Are all the information that are required to reload a model still there after the initial loading?

They should be: A FileHandler stores all that information to provide access to arbitrary files within its hierarchy, and a) it doesn't know when we are done loading all files, and b) it needs to be prepared to write files back.

Another issue can arise when a model gets hot-reloaded while there are still living objects from it around (i.e. instances of GenericElement). These keep a reference to the LXML object, which in turn references back to the entire XML tree.

We could fix / work around this issue by not storing references to the XML tree on the GenericElement objects, but instead storing the UUID and proxying all access to the underlying model through the MelodyLoader. This would require extensive changes in both the GenericElement implementation as well as the Accessor class hierarchy, and incur a minimal performance penalty (we already have a UUID → element hashmap anyways though), but it would also decouple the high level MelodyModel from the fact that the low level loader uses XML - and could therefore potentially enable us to connect to other sources in the future, like directly communicating with a Team4Capella server.


Subscription field does not propagate payload type

When creating a subscriptionField, if one returns a properly typed AsyncIterator it should properly type the root of the resolve method. Unfortunately because the type is T = any, it seems like it overrides the real typing.
Example:
export const MySub = subscriptionField('MySub', {
  type: SomeType,
  resolve: (payload) => {
    // payload is type object
  },
  subscribe: (_root, _args, _ctx) => {
    return createIterator() as AsyncIterator<SomeTypePayload>
  },
})

@Sytten I believe this is fixed in 0.19 - caught some errors in the kitchen sink actually. Can you give it a shot and see if it's any better?

I will trust you on this, I am still on 0.14 and I don't expect I will have time to update for a while... I can test with a pet project to see though.

Doesn't seem to be working:

unknown type for resolver param here https://github.com/graphql-nexus/nexus-plugin-prisma/blob/83c7596dc43f184562d44207af015b84b8b14cda/examples/hello-world/api.ts#L88
and here https://github.com/graphql-nexus/nexus-plugin-prisma/blob/83c7596dc43f184562d44207af015b84b8b14cda/examples/hello-world/api.ts#L97

What is the return type of the method subscribe? I found that sometimes with complex/nested constructs they don't properly bubble up the type of generic parameters. I have this problem with my nexus-shield plugin on objects.

AsyncGenerator<boolean, void, unknown>

@jasonkuhrt I could be wrong, but I don't know if it's possible to use the return type to infer the type usage in resolve. I could go dig up the issue, but I'm pretty sure you need to specify the type annotation of the first arg of resolve, it'll be type-safe (will check that the typing you supply for the source is correct), it's just not inferred.

I think you are right!

I thought that TS was able to infer a generic parameter from the output but it doesn't seem like it. :(

Looks like a TS bug actually https://github.com/microsoft/TypeScript/issues/41456

Closing, since we're technically now correct on the typings, and it's out of scope for Nexus to solve the inference issue.


Move user signals to a separate file.

Load signals when the app is ready.

After #1684 it looks like signals are getting triggered. I suggest we close this one.

Let's see what's wrong with the signals. After that we could separate the signals from the models for a more dry/cleaner approach. I am adding a DNM flag for now


Add Transaction object

This PR is the first of a series of PR to be able to modify Qiita DB to make use of transactions everywhere.
As discussed in the last meeting, instead of modifying the current queue system it will be better to add a Transaction object that encapsulates the transaction.
A few changes from the original design:

The placeholders, instead of being of the form {#:#} -> {query_idx:result_idx} are of the form {#:#:#} -> {query_idx:row_id:value_idx}. This allow for more flexibility and it is easier to reference an actual result. It also removes the need of flattening the results.
The execute method has a boolean parameter commit, optional and default True. This allows to execute all the current queries in the transaction without committing it, which is useful if you need an intermediate result of the transaction to execute some python code (e.g. instantiate an object to retrieve some other information needed for adding more queries to the DB)
The execute methods returns always all the results. You can retrieve then a specific result using the index, or using [-1] to retrieve the result of the last query. This last part was impossible before unless you knew how many results where returned by the last query.

The tests are expected to fail, since the rest of the code has not been modified. Those will be further PR.

Thanks @ElDeveloper ! Comments addressed

Awesome, thanks! :+1:
On (Jun-19-15|14:23), josenavas wrote:

Thanks @ElDeveloper ! Comments addressed

Reply to this email directly or view it on GitHub:
https://github.com/biocore/qiita/pull/1276#issuecomment-113648466

@squirrelo I can't find one of your comments, I assume that you deleted it? If so, please, instead of deleting the comment, comment back saying why no longer applies...

Ready for another pass!

@squirrelo since this is "blocking" your work (or at least that what you stated) you should finish reviewing this PR...

Something I've run into and want to make sure can be done: can you take a list from a query and loop over the results, e.g.
Select all portal ids
loop over ids and add analysis to them
all in a queue.

with execute(commit=False) there are some examples in my other PRs...

Just for completeness, if you want to do that automatically in the queue, makes the placeholders mostly break, since that is technically an executemany, but is done internally and the user do not know that. This makes any future placeholder to be shifted wrt what the user expects, which then makes the placeholders useless. I've already try to find an elegant solution, and the best one is to allow the partial execution of the transaction w/o committing, do some python work, and finish the transaction.
In short, it allows to do any execute_fetch{all/one} without committing and still having the transaction open.

Your example doesn't work as it executes before the queue is filled. I need to create a User and analyses all in one queue, and do what is stated, then edit the user more.  Your example looks like it will leave that user and analysis  in a limbo state

Forget about queues, we are talking about transactions. It is the same transaction as it is not committed... You add some queries to the transaction, you execute them w/o committing, adding some more, and execute them committing. There is an example here.
Also, note that this is allowing you to do what is done internally in the execute_queue, execute a bunch of queries while you're executing some intermediate python and committing at the end.

Does commit=False lock tables?
On Jun 22, 2015 4:53 PM, "josenavas"<EMAIL_ADDRESS>wrote:

Forget about queues, we are talking about transactions. It is the same
transaction as it is not committed... You add some queries to the
transaction, you execute them w/o committing, adding some more, and execute
them committing. There is an example here
https://github.com/biocore/qiita/pull/1276/files#diff-fd8fa1ae44937ec711b82368c103fe10R423
.
Also, note that this is allowing you to do what is done internally in the
execute_queue, execute a bunch of queries while you're executing some
intermediate python and committing at the end.
—
Reply to this email directly or view it on GitHub
https://github.com/biocore/qiita/pull/1276#issuecomment-114259294.

The actual documentation is in here although a bit misleading given the title.
psycopg2 locks the table until a rollback or a commit is done. Since we are not doing any commit/rollback, those tables are locked until the last query is executed, which is when we actually commit.

So, @wasade yes tables are locked as long as you're executing the transaction with the commit=False parameters. However, note that if you forgot to commit and/or rollback, those tables can be locked forever. But this is common in SQL programming, and we didn't hit this issue before because we're auto-committing always.

Yes. Should this be allowed? The chance of a bug impacting the whole
infrastructure is high. If the infrastructure halts, we risk unanticipated
consistency issues.
@squirrelo, can your usecase be expressed as an actual transaction block?
On Jun 22, 2015 5:27 PM, "josenavas"<EMAIL_ADDRESS>wrote:

So, @wasade https://github.com/wasade yes tables are locked as long as
you're executing the transaction with the commit=False parameters.
However, note that if you forgot to commit and/or rollback, those tables
can be locked forever. But this is common in SQL programming, and we didn't
hit this issue before because we're auto-committing always.
—
Reply to this email directly or view it on GitHub
https://github.com/biocore/qiita/pull/1276#issuecomment-114267288.

There is no way we can avoid this. Even in the execute_fetchall function, if the infrastructure halts just before the call to commit is executed, we have the same problem. Or if we completely remove the SQL connection handler and we use plain psycopg2, we have the exact same issue. Example:
         with connect(user=qiita_config.user, password=qiita_config.password,
                      host=qiita_config.host, port=qiita_config.port,
                      database=qiita_config.database) as con:
             with con.cursor() as cur:
                 cur.executemany(sql, sql_args)
             con.commit()

If the system halts between the cur.executemany and the con.commit, will be the exact same situation.
However, I think that this is something that the postgres/psycopg2 developers have already faced and have something in place. In any case, I'm not adding any other issue that is not already in there, and that we can tackle.
Re @squirrelo use case. Yes:
         with connect(user=qiita_config.user, password=qiita_config.password,
                      host=qiita_config.host, port=qiita_config.port,
                      database=qiita_config.database) as con:
             with con.cursor() as cur:
                 cur.executemany(sql, sql_args)
             # Do something in python
             # Do something in SQL
             con.commit()

The overall idea is this. The Transaction object, is simplifying this entire chunk of code by doing:
t = Transaction()
t.add(sql, sql_args, many=True)
t.execute(commit=False)
# Do something in python
t.add("#Do something in SQL")
t.execute()

Yes, this is one reason why execute calls are wrapped in a try/except. This
is a different situation that is not analogous as:
t = Transaction()
t.add(stuff)
t.execute(commit=False)
return None
...will rely on gc if gc picks it up (as resource dependent objects tend to
behave unexpectedly). This is a toy example obviously, but assuming the
developer is always going to write perfect code is risky.
The other scenario I can think of that is concerning is:
t = Transaction()
t.add(stuff)
t.execute(commit=False)
raise ValueError
Will the transaction block rollback in the destructor, or will an exception
take out the whole infrastructure? If it rolls back in the destructor, are
we forced to wait on gc? Are there assurances that gc will pick it up?
On Mon, Jun 22, 2015 at 3:44 PM, josenavas<EMAIL_ADDRESS>wrote:

There is no way we can avoid this. Even in the execute_fetchall function,
if the infrastructure halts just before the call to commit is executed, we
have the same problem. Or if we completely remove the SQL connection
handler and we use plain psycopg2, we have the exact same issue. Example:
     with connect(user=qiita_config.user, password=qiita_config.password,
                  host=qiita_config.host, port=qiita_config.port,
                  database=qiita_config.database) as con:
         with con.cursor() as cur:
             cur.executemany(sql, sql_args)
         con.commit()

If the system halts between the cur.executemany and the con.commit, will
be the exact same situation.
However, I think that this is something that the postgres/psycopg2
developers have already faced and have something in place. In any case, I'm
not adding any other issue that is not already in there, and that we can
tackle.
Re @squirrelo https://github.com/squirrelo use case. Yes:
     with connect(user=qiita_config.user, password=qiita_config.password,
                  host=qiita_config.host, port=qiita_config.port,
                  database=qiita_config.database) as con:
         with con.cursor() as cur:
             cur.executemany(sql, sql_args)
         # Do something in python
         # Do something in SQL
         con.commit()

The overall idea is this. The Transaction object, is simplifying this
entire chunk of code by doing:
t = Transaction()
t.add(sql, sql_args, many=True)
t.execute(commit=False)# Do something in python
t.add("#Do something in SQL")
t.execute()
—
Reply to this email directly or view it on GitHub
https://github.com/biocore/qiita/pull/1276#issuecomment-114272487.

@wasade Reading the psycopg2 documentation here and here we can see that the transaction rollbacks automatically on deletion. Of course, we will depend on gc but I don't think there is a lot that we can do in here (doesn't matter what we do, if we use the transaction object or not, I can see examples that will have the same situation).
However, one thing that popped up while reading such documentation is that it looks like it is not safe to be using a single connection unless we are ensuring that any given call executed within a transaction is not committed, as it will partially commit the transaction.
An alternative will be to use a new connection for each transaction (can be encapsulated in the same transaction object).
Independently of the solution that we reach here, reading all this documentation means that we need to mostly modify all the code in Qiita DB to actually accept a transaction (whatever representation we want of it) as a parameter so we can ensure that all the changes in a given operation are performed in a transactional way.
What do you think?

What I'm generally wondering about is whether we actually need commit=False, or if we can phrase those problems differently? If we need it, then we deal with it. But if there are other ways to go about the problems we're looking at, then we may save ourselves a huge future headache.
It is possible the gc won't trigger as this assumes that psycopg2 doesn't hold references. It may here due to the uncommitted nature.
I don't understand the single connection concern, can you elaborate? The only thing I can think of is:
t = Transaction()
t.add(stuff)
t.execute(commit=False)
# do some other db query
t.add(stuff)
t.execute()

If we

Thinking a little bit more about this, it was a bad idea to use only a single connection. In psycopg2, a connection defines a transaction. At the very first SQL query executed in the connection, psycopg2 defines a transaction and it does not start a new one until it is committed.
What this means is that almost all our qiita_db functions/classes should have a transaction parameter (or connection - if we don't want to use the transaction object), optional, that allow to add the given operations to that transaction if is provided. If the transaction is provided, the function does not commit the changes. If it is not provided, it actually does.
What do people thing about this? Note that this requires a lot of changes that I'm willing to do, but we should reach a consensus soon. Does everybody see the problem that we are currently facing?
cc @antgonza @wasade @adamrp @ElDeveloper @squirrelo

Do people think a call might be useful in here?

I don't understand the concern. Remember, we have a single threaded system,
and our execute calls are committed (right?)
On Mon, Jun 22, 2015 at 4:36 PM, josenavas<EMAIL_ADDRESS>wrote:

Do people think a call might be useful in here?
—
Reply to this email directly or view it on GitHub
https://github.com/biocore/qiita/pull/1276#issuecomment-114288897.

Sorry @wasade I wrote my previous comment before reading yours. An example of the single connection problem:
t = Transaction()
t.add(stuff)
t.execute(commit=False)
value = Study(1).title # !!!
t.add(stuff)
t.execute()

The python code marked with !!! is internally executing a SQL query that at the end commits. Since we have a single connection (shared by the Transaction object and the Study object), the commit inside the Study(1).title will commit half of the transaction. Does this make sense?

That is only a problem if we allow commit=False...
On Mon, Jun 22, 2015 at 4:44 PM, josenavas<EMAIL_ADDRESS>wrote:

Sorry @wasade https://github.com/wasade I wrote my previous comment
before reading yours. An example of the single connection problem:
t = Transaction()
t.add(stuff)
t.execute(commit=False)
value = Study(1).title # !!!
t.add(stuff)
t.execute()
The python code marked with !!! is internally executing a SQL query that
at the end commits. Since we have a single connection (shared by the
Transaction object and the Study object), the commit inside the
Study(1).title will commit half of the transaction. Does this make sense?
—
Reply to this email directly or view it on GitHub
https://github.com/biocore/qiita/pull/1276#issuecomment-114291465.

And further highlights the issues with supporting it
On Mon, Jun 22, 2015 at 4:45 PM, Daniel T. McDonald <
<EMAIL_ADDRESS>wrote:

That is only a problem if we allow commit=False...
On Mon, Jun 22, 2015 at 4:44 PM, josenavas<EMAIL_ADDRESS>wrote:

Sorry @wasade https://github.com/wasade I wrote my previous comment
before reading yours. An example of the single connection problem:
t = Transaction()
t.add(stuff)
t.execute(commit=False)
value = Study(1).title # !!!
t.add(stuff)
t.execute()
The python code marked with !!! is internally executing a SQL query that
at the end commits. Since we have a single connection (shared by the
Transaction object and the Study object), the commit inside the
Study(1).title will commit half of the transaction. Does this make sense?
—
Reply to this email directly or view it on GitHub
https://github.com/biocore/qiita/pull/1276#issuecomment-114291465.

But if we don't allow commit=False, we cannot represent all the possible transactions in the code base. Those transactions that you need to loop over the results of the first query to add the subsequent queries are not representable using the Transaction object. What this means is that in those situations we will need to do:
with conn_handler.get_postgres_cursor() as cur:
   #(1) Do the first query
   #(2) Loop over the results to generate the following queries
   #(3) Execute the next X queries (dependent of the first query)
conn_handler._connection.commit()

However, I think this solution have the same problems that using the transaction object. Example:
with conn_handler.get_postgres_cursor() as cur:
   #(1) Do the first query
   #(2) Loop over the results to generate the following queries
   #(3) Python call with an internal SQL query that commits
   #(4) Execute the next X queries (dependent of the first query)
conn_handler._connection.commit()

In this case (3) will commit our current transaction...

The minimal change here would be for Transaction to instantiate its own
connection. I do not think we should revert SQLConnection back given the
huge prior performance overhead and, in general, a lack of needing multiple
connections.
In the first example, shouldn't that just be done in pure SQL? In other
words, is all this so that Python can be used as a convenience? We are not
the first people to encounter the need to have extended transactions, where
the subsequent database state changes are contingent on the present
database state. How are these handled in, say, SQLAlchemy?
On Mon, Jun 22, 2015 at 4:57 PM, josenavas<EMAIL_ADDRESS>wrote:

But if we don't allow commit=False, we cannot represent all the possible
transactions in the code base. Those transactions that you need to loop
over the results of the first query to add the subsequent queries are not
representable using the Transaction object. What this means is that in
those situations we will need to do:
with conn_handler.get_postgres_cursor() as cur:
#(1) Do the first query
#(2) Loop over the results to generate the following queries
#(3) Execute the next X queries (dependent of the first query)
conn_handler._connection.commit()
However, I think this solution have the same problems that using the
transaction object. Example:
with conn_handler.get_postgres_cursor() as cur:
#(1) Do the first query
#(2) Loop over the results to generate the following queries
#(3) Python call with an internal SQL query that commits
#(4) Execute the next X queries (dependent of the first query)
conn_handler._connection.commit()
In this case (3) will commit our current transaction...
—
Reply to this email directly or view it on GitHub
https://github.com/biocore/qiita/pull/1276#issuecomment-114294281.

I'm cc'ing the entire @biocore/qiita-dev since I've been discussing with @ElDeveloper offline and it turns out that the issue is quite big. I'll try to do my best to summarize the different issues that we have, the potential solutions and the solution that I think is the best one to move forward.
All the problems that we are encountering here is that our modifications to the database are not atomic, i.e. a function that interacts with the database executes multiple commits instead of a single one at the end of the function.
@wasade this is related with your question. The way SQLAlchemy or sqlite handles this situation is by always doing an explicit commit. The problem that we have here occurs due to the implicit commits that the SQLConnectionHandler is doing. As a remainder, those implicit commits were done to avoid ~5 lines of code for each call to the database, which I think is legitimate.
However, when we talk about transactions, the story changes. What should happen is that all the steps executed inside a function are committed at once, or none of them is committed.
Few examples of the current implementation that will leave the system in an inconsistent state:

SampleTemplate.create The DB changes are encapsulated in a transaction. Once the transaction is executed (and committed) the files are generated. However, if there is a problem during the creation of the files, the DB will contain the information although the files are not present in the FS, which is one of our assumptions. This is an inconsistency.
Creating SampleTemplate and PrepTemplate from a QIIME mapping file. If the PrepTemplate creation fails, the SampleTemplate still exists. This is inconsistent. Either both are created or None are created.

The above two examples are from the metadata, but there are other examples in the code. I've used those examples because they allow me to expose the following issue. A function is a transaction itself or not depending on its caller. If we just want to create a SampleTemplate, the function SampleTemplate.create it's a single transaction. However, if we want to create the SampleTemplate and the PrepTemplate from the QIIME mapping file, SampleTemplate.create becomes part of a bigger transaction, so the changes that it performs shouldn't be committed unless the entire, bigger transaction is successfully executed.
This example is an extreme, but this is what is continuously happening in our code with small functions (i.e. calls to check_table, chek_required_columns, etc; in general anything under util.py, but calls like study.title also fall in this category).
Thus, a function should commit or not depending on the context of its caller.
Possible solutions:

This might be possible to solve (not sure 100%) if inside the objects we only use pure SQL queries, and we never use any other python call to the util functions. Drawbacks of this solution: not 100% sure that will work, duplicates a lot of code, small changes in the DB schema might required the rewrite of half of the queries in qiita_db. Advantages: we might gain performance (just a guess... not actual data).
We use the transaction object implemented in this PR and we modify all the API in the qiita_db code base that interacts with the database to accept an optional parameter transaction=None. If the transaction IS NOT provided, the function then creates it's own, and at the end of the function commits the changes. If the transaction IS provided, it adds the queries to the transaction, it potentially executes it with commit=False to return the needed values, and do not commit the changes. Drawbacks of this solution: it changes a lot of the current API. Advantages: i'm 100% that works, allows to represent any kind of transaction, and reduces the code duplication. Since only the function that creates the transactions will commit it, we make sure that it actually works as a transaction. If there is a problem with the creation of the files (first example with the creation of the SampleTemplate) the function will not be committed, so no changes in the database and everything gets clean up.

My vote goes for 2 and I volunteer to change it. I think I can have it done by the end of the week if I start working on this tomorrow morning (or tonight if we reach a consensus earlier).
Sorry for the long comment, but there are a lot of potential issues in our qiita_db code base, and I think it is really important that we solve them ASAP. I will not start working on this until I know that other developers agree. There is a lot of work in here, and I don't want to spend time in something that we're not going to use.

@wasade @squirrelo @ElDeveloper
I've updated the Transaction object to be a context manager. Few things to note:

The Transaction does not try to automatically execute in the __exit__. I've tried it and it generated some unexpected behavior (try to execute things have previously errored). Also, I prefer to have things explicit rather than implicit. Idea: Do not modify the DB if the programmer do not ask for it.
I did not remove the old queue system code. The reason behind this is we can then execute the tests and tests now should pass. I've added a comment in #1262 so we don't forget.
The 'execute' code has been moved to an internal _execute function and the exposed execute wraps the _execute one in a try/except, so we can catch and rollback any changes in there.

I'm having a look at this right now.
On (Jun-23-15|11:30), josenavas wrote:

@wasade @squirrelo @ElDeveloper
I've updated the Transaction object to be a context manager. Few things to note:

The Transaction does not try to automatically execute in the __exit__. I've tried it and it generated some unexpected behavior (try to execute things have previously errored). Also, I prefer to have things explicit rather than implicit. Idea: Do not modify the DB if the programmer do not ask for it.
I did not remove the old queue system code. The reason behind this is we can then execute the tests and tests now should pass. I've added a comment in #1262 so we don't forget.
The 'execute' code has been moved to an internal _execute function and the exposed execute wraps the _execute one in a try/except, so we can catch and rollback any changes in there.

Reply to this email directly or view it on GitHub:
https://github.com/biocore/qiita/pull/1276#issuecomment-114600592

Couple of comments.

This looks pretty good, as for your comment:

Also, I prefer to have things explicit rather than implicit. Idea: Do not modify the DB if the programmer do not ask for it.

When I tested this out on an interactive session, it kinda doesn't make sense to have it as a context manager then, see for example here:
In [24]: with Transaction('foo') as t:
   ....:     t.add('select 42+a')
   ....:

In [25]: t.execute()
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-25-904e3650ed03> in <module>()
----> 1 t.execute()

/Users/yoshikivazquezbaeza/git_sw/qiita/qiita_db/sql_connection.py in execute(self, commit)
    801         """
    802         try:
--> 803             return self._execute(commit=commit)
    804         except Exception:
    805             self.rollback()

/Users/yoshikivazquezbaeza/git_sw/qiita/qiita_db/sql_connection.py in _execute(self, commit)
    752                     # We catch any exception as we want to make sure that we
    753                     # rollback every time that something went wrong
--> 754                     self._raise_execution_error(sql, sql_args, e)
    755
    756                 try:

/Users/yoshikivazquezbaeza/git_sw/qiita/qiita_db/sql_connection.py in _raise_execution_error(self, sql, sql_args, error)
    631             "Error running SQL query in transaction %s:\n"
    632             "Query: %s\nArguments: %s\nError: %s\n"
--> 633             % (self._name, sql, str(sql_args), str(error)))
    634
    635     def _replace_placeholders(self, sql, sql_args):

ValueError: Error running SQL query in transaction foo:
Query: select 42+a
Arguments: []
Error: column "a" does not exist
LINE 1: select 42+a

The context of that transaction had seemingly "exited", but since the execute is never called, then nothing quite happens until you call execute. Therefore either (1) it doesn't make sense to have this as a context manager or (2) we should add an extra argument that controls whether or not changes will be executed once the context is exited. Thoughts?

I'd agree to something in init, like moving commit variable to init instead of on execute. In theory a whole queue should be filled before the execute call, so having the call automatic in __exit__ makes sense, but with this it would execute at the end regardless, and the commit would be controlled by the initial init setting of the queue.

Uhm... Thanks @ElDeveloper. The original idea is that it gets executed inside the context manager, not outside.... I can try to play with it a little bit more and see if I can make it work by automatically executing once it exits the context AND preventing any other call once you're out of the context manager.
That is, if you try to execute this:
with Transaction("t") as t:
    t.add("stuff")
t.execute()

The call to t.execute() will generate an error (it's outside of the context manger, so it's not safe to do it there). Does it make sense?

Are transactions able to execute more than once? If not, a simple "executed" flag should be enough. If they can be run more than once, I guess check for SQL in the queue before executing?

You cannot execute the full transaction more than once, but you can partially execute a transaction (with commit=False).

@josenavas, Yes I think that's the solution that makes the most sense!
On (Jun-23-15|17:06), Joshua Shorenstein wrote:

Are transactions able to execute more than once? If not, a simple "executed" flag should be enough. If they can be run more than once, I guess check for SQL in the queue before executing?

Reply to this email directly or view it on GitHub:
https://github.com/biocore/qiita/pull/1276#issuecomment-114679331

@ElDeveloper, @squirrelo,  there is still one case that I'm still not sure what to do. The case is when there are no more queries to execute, but the latest changes in the DB hasn't been committed. I can see arguments in one way and in another if I should commit them or not...
One reason to commit it automatically is that the developer forgot to commit, so doing it at the exit time makes sense.
However, in a situation like this one:
with Transaction('t') as t:
   t.add("Do changes in the DB")
   t.add("Retrieve some value from the DB")
   value = t.execute(commit=False)[-1][0][0]
   if value == 'something that the developer doesn't want to commit':
       return False
   # Do some other stuff

The return False will make the context manager to actually commit the changes.... We can make clear in the documentation that it will commit automatically, which means that the developer should do this:
with Transaction('t') as t:
   t.add("Do changes in the DB")
   t.add("Retrieve some value from the DB")
   value = t.execute(commit=False)[-1][0][0]
   if value == 'something that the developer doesn't want to commit':
       t.rollback()
       return False
   # Do some other stuff

Do you think this is a good solution?

I'm still not liking the ability to execute without commit in there. You can use if statements in the SQL itself, and there is nothing in the transaction stopping you. I'd say if this is the case, it should be checked at the SQL level, not the python level, that way only things that are supposed to change actually change during the execution.

Actually, the transaction objects are a good example of how we need to take better advantage of SQL's full capabilities, not just simple inserts and updates.

@squirrelo I agree with you, but if we do this, we end up with the other solution, in that everything is executed in pure SQL, doing everything that we need. This means that if something changes in the DB, we may end up needing to update +40 queries across the qiita_db code base.

And we have a system that consistency should be ensured between DB and FS, which means that once the DB is done, doesn't mean that the actual transaction si complete. Today @antgonza had an example: He added a new template to the system, the DB didn't had a problem inserting it, but there was a problem writing the file. This lead the system in an inconsistent state, because we assume that those files exist but they didn't. This end up breaking the interface...

We can still do a hybrid of both. For things like inserts and whatnot, we can break it down by query. But for more complicated things like adding the default analysis for portals, we can take advantage of SQL for loops instead of doing the loop in python and a bunch of SQL inserts lined up. It would still be broken up calls, but more of a melding between SQL and python than the almost totally strict python we are doing right now.
As for the files, if we do the files work inside the transaction with statement, the errors on file stuff will cause the entire thing to roll back, files issues and SQL alike.

@squirrelo, exactly, but sometimes to generate those files you need the data in the DB. Transactions allow you to execute some queries, try to generate the files, and then commit them. There is no other way of doing this consistency that executing one (or many) SQL queries w/o committing and then commit after everything is in place...

Is there a way of querying inside the transaction cursor, as opposed to the database itself? That way you are querying as if the items are already committed, but they actually aren't. I know sqlalchemy can do this.
Alternately, if you need the query information, you can make the query info list available through a function, e.g. get_result(index) so you can use the SQL results without having to commit.

@squirrelo What you're proposing is just executing the query and not commit it. You're saying this:
with connect(params) as con:
    with con.get_cursor() as cur:
        try:
            cur.execute("DO STUFF")
        except:
            con.rollback()
     if checks_pass:
         con.commit()
     else:
         con.rollback()

This the exact same thing that I'm proposing with the commit=False parameter, but the transaction object allows you to do this like this:
with Transaction('t') as t:
    t.add("DO STUFF")
    t.execute(commit=False)
    if not check_pass:
        t.rollback()

Don't let the terminology confuse you, you don't do anything "inside" a cursor, you do it directly to the DB, the difference is that you commit it or not.

Actually what I'm proposing is more like:
with Transaction('t') as t:
    t.add("DO STUFF")
    t.add("QUERY NEEDED STUFF")
    needed_info = t.get_results(t.index-1)
    # use needed info to make files

@squirrelo
And how can I return the result if I don't execute the query w/o committing?
Your proposal, will be doing this internally:
def get_results(index):
    res = self.execute(commit=False)
    return res[-1]

I've found a thing that may fix all our problems: Tornado sessions object This locks a transaction thread until explicitly freed. If this works the way I think it does, we really should be using this as our backend instead of a straight connection like we do now.

You're proposing 2 things:

Removing psycopg2 as a dependency
Coupling qiita_db with tornado.

I don't agree with this, we have already seen that is a bad idea coupling qiita_pet and qiita_db...

Also, I'm not seeing anything about commit/rollback on that documentation... I don't even know how this would work...

That's fair. ISOLATION_LEVEL_SERIALIZABLE might be the best in this case then, which if I'm reading correctly would make the cursor essentially stall the database while running the execution. This is the only way I can see not having the issue of running execute(commit=False) and not worrying about the database changing before the actual database execute with commit.

No, that would not solve the issue.
Let me resume the issue that we have in one sentence:
We are doing commits that we shouldn't do
That's the only problem that we're having, I don't know how else I can explain this.

I get that, but my worry is something else, like another user, starts a transaction and adds something we needed between the commit=false and the actual commit. If this is not a worry and I'm just being paranoid, then OK, but just want to make sure.

The question is, how another user is going to add something that we need? If we need it, we shouldn't be relying in another user to add it.
Also, with commit = False, we are locking the tables, so no other user can modify those tables, which is the idea of SQL transaction.

OK, cool. I'm paranoid then. Carry on.

We can make clear in the documentation that it will commit automatically, ...

Seems like a fine solution to me!

@ElDeveloper @squirrelo This is ready for another review.

BTW, :+1:.

Ready for another review!


functions returning never are not treated the same as raw throw calls in control-flow analysis

TypeScript Version:  2.0.0-beta
Code
function fail(): never {
  throw 'error';
}

enum E {
  A,
  B
}
function f(t: E) {
  let s: string;
  switch (t) {
    case E.A:
      s = 'a';
      break;
    case E.B:
      s = 'b';
      break;
    default:
      fail();  // but replacing with "throw 'error"' removes the TS error.
  }
  s += '';
}

Expected behavior:
s += '' is allowed because all terminating (non-throwing) branches assign to s.
In general, I am working under the assumption that calling functions that returning never are equivalent to raw throw calls during control-flow analysis.
Actual behavior:
ERROR(21,3): : Variable 's' is used before being assigned.

The limitation here has to do with the way the compiler is designed -- control flow analysis happens before typechecking, but we would need type information (as well as identifier resolution) to determine that the fail() call points to a function that is : never, so the s += ''; node is marked as reachable.
The intended fix is to write return fail(); instead of fail();.


AttributeError: 'NoneType' object has no attribute 'get'

env:

sublime text 4
LSP v1.12.1
LSP-typescript v1.6.0
LSP-svelte v1.1.20
node v16.8.0
python v3.7.4
Mac 11.6

when type codes in svelte component's <script> tag, I got error below.
Error handling None
Traceback (most recent call last):
  File "/Users/easyfrog/Library/Application Support/Sublime Text 3/Installed Packages/LSP.sublime-package/plugin/core/sessions.py", line 1616, in on_payload
    handler(result)
  File "/Users/easyfrog/Library/Application Support/Sublime Text 3/Installed Packages/LSP.sublime-package/plugin/core/promise.py", line 153, in <lambda>
    executor_func(lambda value=None: self._do_resolve(value))
  File "/Users/easyfrog/Library/Application Support/Sublime Text 3/Installed Packages/LSP.sublime-package/plugin/core/promise.py", line 214, in _do_resolve
    callback(new_value)
  File "/Users/easyfrog/Library/Application Support/Sublime Text 3/Installed Packages/LSP.sublime-package/plugin/core/promise.py", line 184, in callback_wrapper
    resolve_fn(result)
  File "/Users/easyfrog/Library/Application Support/Sublime Text 3/Installed Packages/LSP.sublime-package/plugin/core/promise.py", line 153, in <lambda>
    executor_func(lambda value=None: self._do_resolve(value))
  File "/Users/easyfrog/Library/Application Support/Sublime Text 3/Installed Packages/LSP.sublime-package/plugin/core/promise.py", line 214, in _do_resolve
    callback(new_value)
  File "/Users/easyfrog/Library/Application Support/Sublime Text 3/Installed Packages/LSP.sublime-package/plugin/core/promise.py", line 178, in callback_wrapper
    result = onfullfilled(resolve_value)
  File "/Users/easyfrog/Library/Application Support/Sublime Text 3/Installed Packages/LSP.sublime-package/plugin/core/promise.py", line 132, in recheck_resolve_status
    resolve(values)
  File "/Users/easyfrog/Library/Application Support/Sublime Text 3/Installed Packages/LSP.sublime-package/plugin/core/promise.py", line 153, in <lambda>
    executor_func(lambda value=None: self._do_resolve(value))
  File "/Users/easyfrog/Library/Application Support/Sublime Text 3/Installed Packages/LSP.sublime-package/plugin/core/promise.py", line 214, in _do_resolve
    callback(new_value)
  File "/Users/easyfrog/Library/Application Support/Sublime Text 3/Installed Packages/LSP.sublime-package/plugin/core/promise.py", line 178, in callback_wrapper
    result = onfullfilled(resolve_value)
  File "/Users/easyfrog/Library/Application Support/Sublime Text 3/Installed Packages/LSP.sublime-package/plugin/documents.py", line 658, in <lambda>
    lambda responses: self._on_all_settled(responses, resolve_completion_list))
  File "/Users/easyfrog/Library/Application Support/Sublime Text 3/Installed Packages/LSP.sublime-package/plugin/documents.py", line 688, in _on_all_settled
    response_items = sorted(response_items, key=lambda item: item.get("sortText") or item["label"])
  File "/Users/easyfrog/Library/Application Support/Sublime Text 3/Installed Packages/LSP.sublime-package/plugin/documents.py", line 688, in <lambda>
    response_items = sorted(response_items, key=lambda item: item.get("sortText") or item["label"])
AttributeError: 'NoneType' object has no attribute 'get'

Solve it: must has a jsconfig.json or tsconfig.jsfon in the project's folder


Bug fixes

Handle OpenStack error state correctly
Add more verbose output to atttribute exception
Await plugin_notification instead of create_task
Optimize Sqlite performance by using exclusive locking and WAL journal
Notify plugins only on state change
Add state transition BootingState -> CleanupState for Stopped VMs
Do not try to drain machines that does not exists anymore in htcondor

Codecov Report

Merging #18 into master will decrease coverage by 0.17%.
The diff coverage is 28.2%.

@@            Coverage Diff             @@
##           master      #18      +/-   ##
==========================================
- Coverage   83.45%   83.27%   -0.18%
==========================================
  Files          37       37
  Lines        1221     1226       +5
==========================================
+ Hits         1019     1021       +2
- Misses        202      205       +3

Impacted Files
Coverage Δ

tardis/adapter/openstack.py
83.82% <ø> (ø)
:arrow_up:

tardis/resources/dronestates.py
30.83% <0%> (ø)
:arrow_up:

tardis/plugins/sqliteregistry.py
100% <100%> (ø)
:arrow_up:

tardis/interfaces/siteadapter.py
73.68% <100%> (+0.71%)
:arrow_up:

tardis/utilities/attributedict.py
100% <100%> (ø)
:arrow_up:

tardis/resources/drone.py
47.61% <25%> (-1.59%)
:arrow_down:

tardis/adapter/htcondor.py
96.77% <66.66%> (-3.23%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e9470ec...929a418. Read the comment docs.


Rebase on Travis Build Stage for releasing

Overview
Lately, Travis has started to mark our releases as errored - https://travis-ci.org/frictionlessdata/datapackage-py/builds/363106512.
It's because we deploy from every build's job. It was only possible way to release previously but now there is Build Stages - https://docs.travis-ci.com/user/build-stages/ - the proper way to do so.

DONE


It is better to add 'Tables' in the description of the setting 'Auto-refresh on change'

Storage Explorer Version: 1.27.0-dev
Build Number: 20221025.2
Branch: main
Platform/OS: Windows 10/Linux Ubuntu 22.04/MacOS Monterey 12.6 (Apple M1 Pro)
Architecture: ia32/x64
How Found: Ad-hoc testing
Regression From: Not a regression
Steps to Reproduce

Launch Storage Explorer -> Open 'Settings -> Data Explorers'.
Uncheck the setting 'Auto-refresh on change'.
Expand one storage account -> Tables.
Create a table -> Try to add one entity.
There is a refresh prompt.

Observe the setting 'Auto-refresh on change' description.
Check whether 'tables' is added in the description.

Expected Experience
Tables is added in the description.
Actual Experience
Tables is not added in the description.

Get rid of calling out specific explorers in the description. At this point in time all data explorers should respect this setting.

Verified this issue on the build main/20221104.1:

The setting 'Auto-refresh on change' description has been updated:

Queues doesn't match this setting currently, and there is a related bug: 3430.

Updates: On the build 20221104.1:

The setting 'Auto-refresh on change' description has been updated:

Queues doesn't match this setting currently, and there is a related bug: 3430.

This should be closed now that the description removed any specific service/explorer in the description. The related bug 3430 should reflect the current description as well.


Allow user to specify order of relu and batch normalization

Batch normalization is there, internal_loss_function added to the generic function, will handle this completely as I more generally rework the networks.


Remove Bookmarked Profiles When Child Status is Inactive

as a user, I need children with statuses other than active to be removed from my bookmark list so I have a better idea of which children are available, and which are not

Tasks

[ ] add a function in the pre-save hook for children to check the status of the child, and if it's something other than active, find all families with that child bookmarked and remove them from the list
[ ] update the family account page tab for bookmarked children to include the following message:

You can bookmark specific child/sibling profiles to track children you have inquired about or wish to inquire about.  Please note that once a child's status is no longer active they will be removed from your Bookmarked Profiles list.

Definition of Done

[ ] children with a status of active will appear as bookmarked by families in their account page
[ ] children with a status of disrupted will no longer appear as bookmarked by families in their account page
[ ] children with a status of on hold will no longer appear as bookmarked by families in their account page
[ ] children with a status of placed will no longer appear as bookmarked by families in their account page
[ ] children with a status of reunification will no longer appear as bookmarked by families in their account page
[ ] children with a status of withdrawn will no longer appear as bookmarked by families in their account page

@bchiaruttini, a little clarification is needed for this story.  Consider the following scenario:

child a has their status set to active
family b bookmarks child a
2a. at this point child a shows up as bookmarked in family b's account page
child a's status is changed to disrupted
3a. at this point child a doesn't show up as bookmarked in family b's account page
child a's status is changed back to active

should child a automatically be added back to family b's bookmarked children in their account page, or should the removal be permanent?

Yes, good question.  The bookmarked profile should automatically be added back to the family’s list should they become reactive again. thanks.
From: Jared Collier<EMAIL_ADDRESS>Sent: Wednesday, May 30, 2018 8:33 AM
To: mareinc/mare
Cc: Bridget Chiaruttini; Mention
Subject: Re: [mareinc/mare] Remove Bookmarked Profiles When Child Status is Inactive (#99)
@bchiaruttinihttps://github.com/bchiaruttini, a little clarification is needed for this story. Consider the following scenario:

child a has their status set to active
family b bookmarks child a
2a. at this point child a shows up as bookmarked in family b's account page
child a's status is changed to disrupted
3a. at this point child a doesn't show up as bookmarked in family b's account page
child a's status is changed back to active

should child a automatically be added back to family b's bookmarked children in their account page, or should the removal be permanent?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/mareinc/mare/issues/99#issuecomment-393144204, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AkIRBUfpDNwaN_52h6BpANqq2mrlj621ks5t3pGMgaJpZM4TNBZu.


Use different empty query for mysql and postgres

Problem
The emptyQuery introduced previously is too complicated.
And mysql has very poor optimise for such queries
Before
mysql> select * from xxx where id in(SELECT 0 FROM (SELECT 0) AS QUILL_EMPTY_SET WHERE 1 = 0);
Empty set (8.54 sec)

After
mysql> select * from xxx where id in(select 0 from dual where false);
Empty set (0.01 sec)

Solution
use different emptyQuery for different dialect
Notes
Additional notes.
Checklist

[x] Unit test all changes
[x] Update README.md if applicable
[x] Add [WIP] to the pull request title if it's work in progress
[x] Squash commits that aren't meaningful changes
[x] Run sbt scalariformFormat test:scalariformFormat to make sure that the source files are formatted

@getquill/maintainers

👍

:+1:


[BugFix]Fix show create table for external table

What type of PR is this：

[x] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Which issues of this PR fixes ：
Fixes #10127
Problem Summary(Required) ：
after execute show create table  command, result miss comma before "host" key for external starrocks table
Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] I have added user document for my new feature or new function

run starrocks_be_unittest

run starrocks_fe_unittest

[FE PR Coverage Check]
:disappointed: fail : 2 / 15 (13.33%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/server/GlobalStateMgr.java
2
15
13.33%
[2153, 2154, 2155, 2156, 2157, 2158, 2159, 2160, 2161, 2162, 2163, 2164, 2165]

run starrocks_admit_test

@mergify backport branch-2.4 branch-2.3


impl PartialEq and PartialOrd with primitives

This rebases and extends #105 (cc @hansihe). As noted before, it may hurt type inference where callers use comparison operators that relied on only one possible impl before. We're on the way to 0.3 though, so even a relatively minor break like that is perfectly allowable.

bors r+

:tada:


chore(deps): update dependency webpack-dev-server to v3.10.2

This PR contains the following updates:

Package
Type
Update
Change

webpack-dev-server
devDependencies
patch
3.10.1 -> 3.10.2

Release Notes

webpack/webpack-dev-server
v3.10.2
Compare Source

Renovate configuration
:date: Schedule: At any time (no schedule defined).
:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.
:recycle: Rebasing: Whenever PR becomes conflicted, or if you modify the PR title to begin with "rebase!".
:no_bell: Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

Available now for Enterprise: Renovate Pro with real-time webhook handling and priority job queue.

:tada: This PR is included in version 3.0.22 :tada:
The release is available on:

v3.0.22
GitHub release

Your semantic-release bot :package::rocket:


Consolidate Intrinsic and Canon under Microsoft.Quantum.Core

Consolidate Intrinsic and Canon under Microsoft.Quantum.Core
Conceptual overview
The Q# compiler auto-opens namespace Microsoft.Quantum.Core, whereas iQ# (the Jupyter kernel for Q#) also auto-opens Microsoft.Quantum.Intrinsic and Microsoft.Quantum.Canon. I believe the choice to open these automatically in iQ# was made before open namespaces were shared between notebook cells in iQ#, but this raises a good point:
opening Microsoft.Quantum.Intrinsic and Microsoft.Quantum.Canon amounts to boilerplate required for almost any Q# program. Examples:

All 32/32 of the solutions to the QuantumKatas open Microsoft.Quantum.Intrinsic, and 22/32 solutions open Microsoft.Quantum.Canon
All of the project templates included in the VSCode extension open both these two namespaces
Of the 115 Q# files in samples/ in the Microsoft/Quantum repository, 109 files open Microsoft.Quantum.Intrinsic, and 91 open Microsoft.Quantum.Canon

Proposal

Move everything from Microsoft.Quantum.Intrinsic and Microsoft.Quantum.Canon into Microsoft.Quantum.Core.
Impact of breaking changes

Assuming the two namespaces still exist (albeit empty), programmers will not affected except for:

Programmers who did not open either namespace, but defined their own e.g. H() operation in their own namespace. If they open their namespace and call their H(), they will get an AmbiguousCallable error

Can't find examples of this outside of qsharp-runtime

Programmers using the fully qualified name to access something in Microsoft.Quantum.Intrinsic or Microsoft.Quantum.Canon

Can't find examples of this outside of qsharp-runtime

Programmers opening Microsoft.Quantum.Intrinsic or Microsoft.Quantum.Canon with an alias

Can't find examples of this outside of qsharp-runtime

If my searching is failing and programmers are doing any of these 3 things, it's tough to think of a migration path. Leaving @Deprecated stubs in Microsoft.Quantum.Intrinsic and Microsoft.Quantum.Canon that call into Microsoft.Quantum.Core may not work, since if someone opens Microsoft.Quantum.Intrinsic or Microsoft.Quantum.Canon, if they call anything from either of those namespaces, then they'll get a AmbiguousCallable error between the new callable and the stub.
One idea could be allowing attributes on namespaces so we can @Deprecate both Microsoft.Quantum.Intrinsic and Microsoft.Quantum.Canon. Hopefully that could provide a more useful error message than the confusion programmers would see for (1)-(3) above, and it opens a path to eventually removing both namespaces.
Alternatives considered

An alternative is to have the compiler open Microsoft.Quantum.Intrinsic and Microsoft.Quantum.Canon by default. However, this is not as clean as always opening a single namespace: it seems like a slippery slope to continue adding more auto-opened namespaces to the compiler.

Thanks for opening this! To explain a bit of the thinking behind the split between Core, Intrinsic, and Canon, Core is the set of functions and operations needed to support Q# as a language at all — e.g.: Length is required in order for the language to make sense and to be coherent.
By contrast, one can imagine writing Q# programs that use a different QIS than that represented by Microsoft.Quantum.Intrinsic. Similarly, not all devices will support the combinator logic and similar utilities collected in Microsoft.Quantum.Canon. Thus, there's a real and material sense in which Microsoft.Quantum.Core is more "fundamental" than the other two, reflected in the auto-open behavior. Collapsing all of them into one namespace may be confusing as a result.
Definitely all for reducing boilerplate, though; we maybe could look to C#'s recent efforts (Q# is not C#, obviously, but we do learn from development in a variety of languages, including Python, Rust, and C#). In particular, when using .NET 6-style projects, a reasonable set of using statements is added by default, but that behavior can be turned off with a csproj property.
As another potential option, Rust's compact notation for opening namespaces may be helpful; e.g.: something like open Microsoft.Quantum.{Canon, Intrinsic};.
One other option may be to use F#-style @AutoOpen attributes. In F#, those can only be used from projects compiled as part of building the standard libraries, but it allows for decoupling auto-open decisions from the compiler implementation itself.
All by way of agreement, it would be good to reduce boilerplate — we may want to explore some other alternatives as to how to do so, though.

Rust, Haskell and other languages have a prelude, which is a module that is automatically imported in every file.

To explain a bit of the thinking behind the split between Core, Intrinsic, and Canon, Core is the set of functions and operations needed to support Q# as a language at all — e.g.: Length is required in order for the language to make sense and to be coherent.

Preludes usually re-export things defined in other modules (for example, see all the random things that std::prelude has). That's analogous to leaving things in Core, Intrinsic and Canon, but re-exporting them under either Core or a new prelude namespace.

By contrast, one can imagine writing Q# programs that use a different QIS than that represented by Microsoft.Quantum.Intrinsic. Similarly, not all devices will support the combinator logic and similar utilities collected in Microsoft.Quantum.Canon.

Preludes can be replaced. In Haskell, it's possible to turn off the default prelude and use another one that you like or more or that's more suited to a particular project. In Rust, it's common to see use foo::prelude::*; to get access to domain-specific utilities from a library. But I think it's important that there's one prelude module, rather than three, to make it easier on users.

I'm closing this in favor of preludes since (in my opinion) Cassandra is correct above


Enhancement: Distribute the commission of the delegators

Use Imbalances distribute the author share + commission percentage to the delegators based on the ratio total_stake/delegator_stake.

This is done but need thorough test with actual computation: https://github.com/Xode-DAO/xode-blockchain/commit/3605da34e27e28c7e98d657d700bf404488d4ee8


Popup/Tooltip content function: allow return undefined

In this case Popup/Tooltip is not shown.
Usefull when only some sublayers need popups:

previously: it was necessary to attach independent popups to each sublayer
now: it's enough to have common content function attached to parent layer

This change is

WIP

simple approach: just close empty popup.

Although this works for me, but some tests in PhantomJS failed.
Waiting for advice.

Patch reworked, now all tests are happy.
N.B.
openTooltip and openPopup contain pretty the same code, I suppose it'd be better refactored (place common function in DivOverlay)

Close in favor of #6651


Can't install OpenBLAS on 2015th MacBook Pro 13.

I want to install OpenBLAS on my MacBook Pro 13 (i5-5XXX CPU, intel integrated graphics).I tried to install OpenBLAS form homebrew-science and source code. They both failed with the same error message.
I googled and found the reason may be the new CPUs( broadwell architecture)
have not been adapted. Can any one help or give a workaround?
Part of the Error Message :
printf("#define DLOCAL_BUFFER_SIZE\t%ld\n", (DGEMM_DEFAULT_Q * DGEMM_DEFAULT_UNROLL_N * 2 * 1 * sizeof(double)));
^
getarch_2nd.c:69:50: error: use of undeclared identifier 'CGEMM_DEFAULT_Q'
printf("#define CLOCAL_BUFFER_SIZE\t%ld\n", (CGEMM_DEFAULT_Q * CGEMM_DEFAULT_UNROLL_N * 4 * 2 * sizeof(float)));
^
getarch_2nd.c:69:68: error: use of undeclared identifier 'CGEMM_DEFAULT_UNROLL_N'
printf("#define CLOCAL_BUFFER_SIZE\t%ld\n", (CGEMM_DEFAULT_Q * CGEMM_DEFAULT_UNROLL_N * 4 * 2 * sizeof(float)));
^
getarch_2nd.c:70:50: error: use of undeclared identifier 'ZGEMM_DEFAULT_Q'
printf("#define ZLOCAL_BUFFER_SIZE\t%ld\n", (ZGEMM_DEFAULT_Q * ZGEMM_DEFAULT_UNROLL_N * 2 * 2 * sizeof(double)));
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
make: *** [getarch_2nd] Error 1
Makefile:131: *** OpenBLAS: Detecting CPU failed. Please set TARGET explicitly, e.g. make TARGET=your_cpu_target. Please read README for the detail.. Stop.

Which version are you trying to install ? 0.2.15 was released this week, anything packaged by third party may still be 0.2.14. ("make clean; make TARGET=HASWELL" would probably work with 0.2.14, I believe 0.2.15 will detect Broadwell automatically)

@martin-frbg  Thanks very much.  By using 0.2.15, I works fine.


Download the MinGW installer from the MinGW website. Run the installer and select the gcc component.

wich?

normally this one


Unable to flag spam: can't find flagging option

Details

Read the Docs project URL: https://readthedocs.org/projects/windows-support-800-214-7840/
Build URL (if applicable):
Read the Docs username (if applicable): https://readthedocs.org/profiles/paulisteni/

Expected Result
Flag option on project page to report spam project
https://github.com/rtfd/readthedocs.org/blob/43073b15999d18f96532682ba838717521119abf/readthedocs/templates/projects/includes/flagging.html
Actual Result
Logged in, trying to report the above project as spam, but I can't find anywhere to do it on the page.

The flagging in https://github.com/rtfd/readthedocs.org/blob/43073b15999d18f96532682ba838717521119abf/readthedocs/templates/projects/includes/flagging.html is not loaded anywhere

We don't have a feature for this and I don't think we will add this either. We don't have resources to continually remove spam projects, and automating this is a great way to open up ourselves to abuse. Closing this support and moving to #5227


Angular Select select as label for value in array syntax broken for nullable

select as label for value in array shows an empty box if we drive the nullable from the model
For example for model
$scope.colors = [
      {name:'nothing', shade:null},
      {name:'red', shade:'dark'}
    ];

compare good version (color.name for color in colors)

with bad version (color.shade as color.name for color in colors)

Sample : http://plnkr.co/edit/MLgOTj9tjd9HF56Jm5RU?p=preview

This is fixed by #10639. See http://plnkr.co/edit/pf0EIrZbb9qXa7Oqy6kc?p=preview


Unsafe warning

I have this warning on v4.2.1.stable.official, no sure if this is something of concern ?
InputManager.gd:288 @ _emit(): An input event object is being parsed more than once in the same frame, which is unsafe.
If you are generating events in a script, you have to instantiate a new event instead of sending the same one more than once, unless the original one was sent on an earlier frame.
You can call duplicate() on the event to get a new instance with identical values.
  <C++ Source>   core/input/input.cpp:962 @ parse_input_event()
  <Stack Trace>  InputManager.gd:288 @ _emit()
                 InputManager.gd:210 @ _handle_screen_drag()
                 InputManager.gd:129 @ _unhandled_input()

I'm not sure what problems this could cause, but I created PR #41 which seems to fix the warning.
I would appreciate it if you could test it and let me know if it worked.

I got the same warnings and the fix worked for me.

@Solomar Thanks for letting me know.


Add MTLLoader, with support for .obj+.mtl pairs. (v. 2)

Updated version of #747, rebased against dev branch.
three-dev no longer has a separate OBJMTLLoader (which does seem cleaner) – they've rewritten OBJLoader to work with MTLLoader, and I've made a few changes here to take care of that.

Thanks for this and sorry for the extra work!


made the changes you suggested as well as adding to the CLI

I noticed you allowed maintainers to allow edits to your branch, I can go ahead and do these for you if you wish!

I've gone ahead and resolved those changes! Doing final testing.

LGTM! Thanks for the contribution, our Discord is at https://rpi.tv/join if you want to contribute more.


mismatch between documentation and implementation of delete endpoints /event/device/{deviceId} and reading/device/{deviceId}/{limit}

🐞 Bug Report
Tested with Insecure EdgeX Foundry instance using Redis database
There is a mismatch between the documented supported APIs and the implementation when using redis database.
Openapi core-data.yaml file says:
https://github.com/edgexfoundry/edgex-go/blob/5d263c9336f050d061fc6f0f587533ef9146dd01/api/openapi/v1/core-data.yaml#L105-L116
description: The ID or name of the device associated  to events
(Tested with Redis database only)
This endpoint works only when deviceName is provided.
If deviceId is provided - there is no error, but nothing happens (no events are deleted)
Same issue appears  when trying to list reading by device
Openapi core-data.yaml :
https://github.com/edgexfoundry/edgex-go/blob/5d263c9336f050d061fc6f0f587533ef9146dd01/api/openapi/v1/core-data.yaml#L357-L373
The description for deviceId parameter is Device ID or device name
(Tested with Redis database only)
The endpoint list device readings limited by a number only if deviceName is provided.
If deviceId is provide nothing happens - there is no error, but the returned list is empty

Here are my insights after a research why such mismatch exists.

First of all, It figured out that the issue is not directly related with the underling database that is in use. So, I will rename the  issue removing Redis as a main reason of the issue. (@andresrinivasan )

If I understand correct, these endpoints are intentionally created to work with both deviceId and deviceName. Actually the list of endpoints is larger.
Events related endpoints:
DELETE:   /v1/event/device/{deviceId}
GET:          /v1/event/device/{deviceId}/{limit}
GET:          /v1/event/count/{deviceId}
Readings related endpoints:
GET:        /v1/reading/device/{deviceId}/{limit}
GET:        /v1/reading/name/{name}/device/{device}/{limit}

The functionality that is supposed to validate and retrieve the device, no matter what is the provided parameter - deviceId or deviceName, is part of metadata endpoint GET: /v1/device/check/{token} The description of this endpoint is : Obtain a device by either name or ID, where the ID must be a valid GUID.

So core-data or all the above endpoints make a call to core-metadata in order to retrieve the device, no matter what is the input parameter. But the problem comes that they do not care of the returned result. They just take care if the device exists or not. And they continue with logic manipulating the database using the parameter that comes from the user (that could be both deviceId/ deviceName) But what is the device data actually saved in the database under reading.Device and event.Device - the device ID or device Name ?!

For both event and reading Create requests there is not restriction/validation what should be provided for filed Device - So, both device Id and Name could be provide ..or any other string?  Am I missing somethings here ?

In my understanding, the database format should be strictly specified. Then we could have endpoints that could handle double-purpose input parameters.  (@lenny-intel, @jpwhitemn )

When receiving event in core-data, there is a chance to validation the device field of Event
https://github.com/edgexfoundry/edgex-go/blob/07eb6246d5fb2c01df3c6ba4777e936c65ab9351/cmd/core-data/res/configuration.toml#L3
However, it still calls GET: /v1/device/check/{token}
Thus, id or name could both pass the check.
In Device Service SDK, we always send Event with device name, not id.
@difince I am not sure whether we should change it in V1 API because it might break the backward compatibility.
@jpwhitemn @lenny-intel we could decide whether we should restrict to name only in V2 API

@cloudxxx8 I agree for not changing API v1
Let consider that for API v2 the evens are created using the device name only.
All other GET requests could use this double purpose parameter - or be responsive on both deviceName And deviceId

@difince in V2 API, we have two checks for name and id respectively
https://app.swaggerhub.com/apis-docs/EdgeXFoundry1/core-metadata/2.x#/default/get_device_check_id__id_
https://app.swaggerhub.com/apis-docs/EdgeXFoundry1/core-metadata/2.x#/default/get_device_check_name__name_

Thank you @cloudxxx8
So, the issue is not going to exists in API v2.
Anyway the issue is present  in API v1 and ...probably is not going to be fixed? Should the issue stay open  just to mark that the issue is known ?

@difince since we will not fix in V1 and will not exist in V2, I suggest we can close this issue with "wontfix" label.  Is it ok with you?

Yep, it is ok. Thank you @cloudxxx8
The issue is not going to exists within API v2, But will still remain in API v1 and won't be fixed.


Guideline about overriding SVG icons

In the doc, there is no straight-forward guideline about overriding the back and forward icons. So I jumped into the source code and found out that you need to pass an object to svgIconOverrides attribute.
https://github.com/gabrielbusarello/material2-carousel/blob/78de02cf82d2747fc06982820167e93bc41c63f6/projects/carousel/src/lib/carousel.ts#L25-L28
Here I tried all possible ways to change the default icons, but no luck!
@gabrielbusarello, can you help please?

@msrumon, you do it like this:
Copy svg icons to assets folder.
Then, prepare the svgIconOverrides object and register your svg icons inside component.ts file:
import { Component, Input, OnInit } from '@angular/core';
import { MatIconRegistry } from '@angular/material/icon';
import { DomSanitizer } from '@angular/platform-browser';
import { SvgIconOverrides } from '@ngbmodule/material-carousel';
import { Item } from './item.model';

@Component({
  selector: 'app-item',
  templateUrl: './item.component.html',
  styleUrls: ['./item.component.scss']
})
export class ItemComponent implements OnInit {
  @Input()
  item: Item;

  icons: SvgIconOverrides = {
    arrowBack: 'arrow_back',
    arrowForward: 'arrow_forward'
  };

  constructor(iconRegistry: MatIconRegistry, sanitizer: DomSanitizer) {
    iconRegistry.addSvgIcon(
      'arrow_back',
      sanitizer.bypassSecurityTrustResourceUrl('../../../../assets/images/layout/arrow-back.svg')
    );

    iconRegistry.addSvgIcon(
      'arrow_forward',
      sanitizer.bypassSecurityTrustResourceUrl('../../../../assets/images/layout/arrow-forward.svg')
    );
  }

  ngOnInit() {}
}

Then, place your carousel inside your component.html file:
  <div [style.height]="'auto'">
    <mat-carousel
      timings="250ms ease-in"
      [autoplay]="false"
      color="primary"
      maxWidth="auto"
      slides="8"
      [loop]="true"
      [hideArrows]="false"
      [hideIndicators]="false"
      [useKeyboard]="true"
      [useMouseWheel]="false"
      [maintainAspectRatio]="true"
      [proportion]="(300 / 321) * 100"
      orientation="ltr"
      [svgIconOverrides]="icons"
    >
      <mat-carousel-slide
        #matCarouselSlide
        *ngFor="let slide of item.images; let i = index"
        [image]="'./assets/images/gallery/items/' + slide"
        [hideOverlay]="true"
      ></mat-carousel-slide>
    </mat-carousel>
  </div>

Hi, thanks for the response @micobarac.
Sorry for late, but this year is been so much tiring, I will take care of this project more, but it's hard by now, sorry one more time.
I have some features annoted for do to this project, but I have no time yet, if still have any issues in this case, let me know, and I will take care of it.
Stay safe! Hugs!

@gabrielbusarello, thanks for this great library!. 🍻🍻🍻

Thanks to both of you. It's been late, but I figured it out way back (maybe after 2 days from issuing this ticket) by looking at the source code. Anyway, I wish all the best for this library.


Change "newsItems" to "logItems" | Fix "subDay"

This talked about "newsItems" but they are "logItems".
Change "subDay()" to "subYear()" and adjust English to match. It previously was trying to say "more than a year ago" but the code example subtracted a day (not a year).
Technically a model uses a trait so reworded it thus.
Insert "on" to make more idiomatic in Changelog sentence.

Thanks!


Add inbound license notice

Contributors need to be made aware of the terms and conditions under which they contribute to this repository.

Codecov Report

Merging #107 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #107   +/-   ##
=======================================
  Coverage   89.88%   89.88%
=======================================
  Files          12       12
  Lines         168      168
  Branches        6        6
=======================================
  Hits          151      151
  Misses         17       17

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c80cf7c...f2b6aea. Read the comment docs.

👍

Thanks!

:+1:


Feature/server network profiles

Adding management of 'Server Network Profiles' to Citrine.
These represent the Websocket Server Config objects used to manage Citrine's websocket servers.
They can be linked to SetNetworkProfile messages via ChargerNetworkProfile objects.
Server Network Profiles updated from config on every startup using Server/
'SetNetworkProfile' objects added to track SetNetworkProfileRequests.
@AsMessageApi decorator extended in order to allow custom query params in addition to the 3 defaults. SetNetworkProfile message api extended with 'websocketServerConfigId' in order to associate message with Citrine's websocket servers. Since SetNetworkProfileRequest details usually refer to cloud infrastructure, mapping them to Citrine's internal representation of its websocket servers must be done explicitly like this and cannot be inferred (as hosts & ports & configuration slots will not match).
New AuthenticationFilter added for test case TC_A_19_CSMS. This will reject connection attempts from charging stations whose OCPPCommCtrlr.NetworkConfigurationPriority value only includes references to higher security profiles than the one the charging station is trying to connect with.
Notes: This filter does not attempt to work if any of the configured NetworkProfiles are not matched with Citrine's internal websocket server configurations, in order to avoid charger lockout. Although this feature is required by the specification, in the field this will only occur when a charger either breaches the protocol by attempting to connect with a Network Profile it doesn't have configured or when a charger has its configuration adjusted outside of OCPP communication. Due to the former being unlikely and the latter requiring human intervention, it is unwise to be overly prescriptive and risk unnecessary charger lockout.

Can we fix lint 🙏


ERROR: {"error": "Connection failed!\n\nThe error message returned was:\nNo module named psycopg2"

Make sure these boxes are checked before submitting your issue - thank you!

[ yes] I have checked the superset logs for python stacktraces and included it here as text if any
[yes ] I have reproduced the issue with at least the latest released version of superset
[ yes] I have checked the issue tracker for the same issue and I haven't found one similar

Superset version
0.18.5
Expected results
I am trying to connect superset to postgresql. I use this url  :
postgresql+psycopg2://user:pwd@ip:5432/mydatbase.
Before run test connection i install pip install psycopg2 and i don't understant why i have this error :
ERROR: {"error": "Connection failed!\n\nThe error message returned was:\nNo module named psycopg2"
Actual results
ERROR: {"error": "Connection failed!\n\nThe error message returned was:\nNo module named psycopg2"
Steps to reproduce
No

First please close #3151 as you have already been asked to. Second read the installation documentation as it's documented what you have to install for talking to postgresql databases.

how did u solve it?I have the same problems

Hi,
You need to install this : pip install psycopg2
Please follow documentation : Database dependencies
https://superset.incubator.apache.org/installation.html

pip install psycopg2

Now we need to install the binary

pip install psycopg2-binary

I faced the exact same issue, and finally realized it was b/c i was installing the pkgs on my computer but that superset was installed in a virtual environment.  I just posted the following answer to stack overflow.  I hope it helps ppl:
you may have installed superset in a virtual environment as suggested in the install guide
A good indicator is to search for where you installed superset and if it's in a folder venv, it's likely in the virutal environment.
You need to ensure that the python packages are installed in your virtual environment as well.  Installing on your local computer will not work.
Go to where you installed superset (in my case /Applications/venv/), and activate the venv:
. venv/bin/activate
Install your packages
pip install psycopg2


[11.x] Fix attribute mutator access in loadMissing

Issue
When using ->loadMissing collection method on a nested relationship it can cause all the models in the collection to be converted to JSON which causes attribute mutators to be accessed. This is normally not a problem, unless the mutators need to access other relationships, in which case it can become an issue as certain relationships can get loaded unnecessarily.
Proposed Solution
The cause is the use of ->whereNotNull collection method, which leads to the JSON conversion. The PR changes that bit to a simpler ->filter access.
Additional Context
Backtrace when using ->whereNotNull

array:105 [▼
  ...app code

  8 => array:3 [▼
    "file" => "/home/.../vendor/illuminate/database/Eloquent/Concerns/HasAttributes.php"
    "line" => 689
    "function" => "getContentAttribute"
  ]
  9 => array:3 [▼
    "file" => "/home/.../vendor/illuminate/database/Eloquent/Concerns/HasAttributes.php"
    "line" => 739
    "function" => "mutateAttribute"
  ]
  10 => array:3 [▼
    "file" => "/home/.../vendor/illuminate/database/Eloquent/Concerns/HasAttributes.php"
    "line" => 277
    "function" => "mutateAttributeForArray"
  ]
  11 => array:3 [▼
    "file" => "/home/.../vendor/illuminate/database/Eloquent/Concerns/HasAttributes.php"
    "line" => 215
    "function" => "addMutatedAttributesToArray"
  ]
  12 => array:3 [▼
    "file" => "/home/.../vendor/illuminate/database/Eloquent/Model.php"
    "line" => 1664
    "function" => "attributesToArray"
  ]
  13 => array:3 [▼
    "file" => null
    "line" => null
    "function" => "Illuminate\Database\Eloquent\{closure}"
  ]
  14 => array:3 [▼
    "file" => "/home/.../vendor/illuminate/database/Eloquent/Concerns/PreventsCircularRecursion.php"
    "line" => 46
    "function" => "call_user_func"
  ]
  15 => array:3 [▼
    "file" => "/home/.../vendor/illuminate/database/Eloquent/Model.php"
    "line" => 1663
    "function" => "withoutRecursion"
  ]
  16 => array:3 [▼
    "file" => "/home/.../vendor/illuminate/database/Eloquent/Model.php"
    "line" => 1695
    "function" => "toArray"
  ]
  17 => array:3 [▼
    "file" => "/home/.../vendor/illuminate/database/Eloquent/Model.php"
    "line" => 1680
    "function" => "jsonSerialize"
  ]
  18 => array:3 [▼
    "file" => "/home/.../vendor/illuminate/database/Eloquent/Model.php"
    "line" => 2391
    "function" => "toJson"
  ]
  19 => array:3 [▼
    "file" => "/home/.../vendor/illuminate/support/helpers.php"
    "line" => 68
    "function" => "__toString"
  ]
  20 => array:3 [▼
    "file" => "/home/.../vendor/illuminate/support/helpers.php"
    "line" => 166
    "function" => "blank"
  ]
  21 => array:3 [▼
    "file" => "/home/.../vendor/illuminate/support/helpers.php"
    "line" => 483
    "function" => "filled"
  ]
  22 => array:3 [▼
    "file" => "/home/.../vendor/illuminate/collections/functions.php"
    "line" => 20
    "function" => "transform"
  ]
  23 => array:3 [▼
    "file" => "/home/.../vendor/illuminate/collections/Traits/EnumeratesValues.php"
    "line" => 1097
    "function" => "Illuminate\Support\enum_value"
  ]
  24 => array:3 [▼
    "file" => null
    "line" => null
    "function" => "Illuminate\Support\Traits\{closure}"
  ]
  25 => array:3 [▼
    "file" => "/home/.../vendor/illuminate/collections/Arr.php"
    "line" => 930
    "function" => "array_filter"
  ]
  26 => array:3 [▼
    "file" => "/home/.../vendor/illuminate/collections/Collection.php"
    "line" => 395
    "function" => "where"
  ]
  27 => array:3 [▼
    "file" => "/home/.../vendor/illuminate/collections/Traits/EnumeratesValues.php"
    "line" => 623
    "function" => "filter"
  ]
  28 => array:3 [▼
    "file" => "/home/.../vendor/illuminate/collections/Traits/EnumeratesValues.php"
    "line" => 645
    "function" => "where"
  ]
  29 => array:3 [▼
    "file" => "/home/.../vendor/illuminate/database/Eloquent/Collection.php"
    "line" => 274
    "function" => "whereNotNull"
  ]
  30 => array:3 [▼
    "file" => "/home/.../vendor/illuminate/database/Eloquent/Collection.php"
    "line" => 245
    "function" => "loadMissingRelation"
  ]
  31 => array:3 [▼
    "file" => "/home/.../vendor/flarum/core/src/Api/Endpoint/Concerns/HasEagerLoading.php"
    "line" => 128
    "function" => "loadMissing"
  ],

  ...app code
];

@SychO9 thanks! This issue very nearly drove me insane.


Interface proposal for the split TD partitioning VMM

This draft PR is opened to collect review comments and discussions, but not to merge.
The TD partitioning VMM was implemented fully in the coconut-svsm kernel mode, which runs the coconut-svsm as a L1 VMM in TD and a Linux OS as a L2 guest. The code is published here.
Following the development plan, most parts of this TD partitioning VMM should be moved to the user mode for security reasons, while keeping the necessary parts (e.g., executing TDCALL instruction) left in the svsm kernel. We made a document, available for preview  here, which discusses the high-level architecture of the split TD partitioning VMM and outlines the key VMM interfaces between user mode and kernel mode. In short, the proposal is to use the common file based syscalls ABI, e.g., open, ioctl, mmap as the VMM interfaces, and clone syscall to create multiple vCPU threads which shares the same user mode address space.
Before moving forward, we would like to use this PR to collect the review comments from the community about this proposal and possibility of extending it for SEV user mode VMM, as well as any alternative proposals that the community prefers. We would greatly appreciate it if you could take some time to review and share your thoughts.

The markdown doc is converted to a  pdf file, which is now uploaded to this PR.

Hi @joergroedel, this document is updated with describing a basic vcpu run loop implementation in the user mode VMM to enter guest and handle simple vmexit event, with utilizing the syscalls outlined in the X86-64 Syscall API/ABI Document. And here is the pdf version. Would you please let us know if this is on the right direction or not? Thanks!