OpenIddictAuthorizations.CreationDate is always null - openiddict

OpenIddict v3.0.3
When rows are added to the table OpenIddictAuthorizations, the column CreationDate is never populated.
Refering to model class OpenIddictEntityFrameworkAuthorization.CreationDate.
https://github.com/openiddict/openiddict-core/blob/750f8422733f7a74cbbf9769a18ad08900ebecf5/src/OpenIddict.EntityFramework.Models/OpenIddictEntityFrameworkAuthorization.cs
What could be missing? Any hint is appreciated.
Our implementation of OpenIddict has been upgraded during development when OpenIddict has been updated, so something may be missed along the road.

You can attach the creation date to the descriptor when using the overload accepting an OpenIddictAuthorizationDescriptor instance.
That said, I opened https://github.com/openiddict/openiddict-core/issues/1247 to update the other overload to populate the creation date automatically.

Related

Reference of previous activity without naming it

In ADFv2 the expression allows referencing the activity by #activity('ActivityName') which can be used to get the output or error. Is it possible to get a reference to the previous activity without knowing or coding the name in the expression?
Is it possible to get a reference to the previous activity without
knowing or coding the name in the expression?
No such feature in ADF as i know. I tried to provide a property here for your reference which you may utilize: DependsOn.This property describes the dependencies between components.If multiple activities are caused by previous activity with different statuses,it will be constructed into an array.
But it is not for usage in the expression,it could be get and set in the sdk. You could refer to some snippet of this case(Python Azure Data Factory Update Pipeline) ,especially for ActivityDependency.

ReferenceManyField, ReferenceArrayField

I'm trying to build a admin app with admin-on-rest connected to Graph.cool. I's working except the relational references. On graph.cool we set up a related field to another "type" and the created fields are array of objects with a related id prop and the related type.
But admin-on-rest spect a single array of ids. I could change my schema but it will broke my database on graph.cool.
I tried some source="??" on the component but no lucky. Any ideias ? Thanks
That should be handled by the client. I'm afraid it's not implemented yet. You're welcome to give it a try if you like. Otherwise, you'll have to wait until I get some time for it

How do i use cache in kettle pentaho?

I am processing data, where i get some information from rest api, based on the value of a field.
Now, value may repeat for that field and if I already have fetched the data for that value, from REST, i would like to reuse that value and saving an API call (slowest operation in the transformation).
is is possible? if yes, how?
Regards
Ajay
#RFVoltini you are right, maybe we could try to setup a H2 db server for this purpouse: http://type-exit.org/adventures-with-open-source-bi/2011/01/using-an-on-demand-in-memory-sql-database-in-pdi/
other option is using memcached in java : http://sacharya.com/using-memcached-with-java/
I've did an example transformation, that gets from a webservice country names by country codes. I've used the idea where you just need to get from the webservice the distinct country codes/names then lookup them on your main pipeline.
Take a look at this example: https://docs.google.com/open?id=0B-AwXLgq0XmaV0V0cHlfTFZlVUU and see if this method applies to you.

Can I get NHibernate to enforce that a string property is non-empty?

I know about the not-null attribute. Is there one for enforcing the minimum length of a string property? I don't want empty strings in my database.
I don't know of anything in the mapping file that will let you do this (and I don't see anything in the schema). You could probably define a custom type using NHibernate.IUserType and build your logic into that type (if the string is empty save null). Here is an example of building an IUserType (it would be easy to change this example code to work for you)
The other option is to take advantage of NHibernate.Validations and to handle the validation logic before getting to the point where you are saving the entity to the database.
You are looking for NHibernate Validator! There's a blog post here showing some of its goodness.

Best Way to Handle SQL Parameters?

I essentially have a database layer that is totally isolated from any business logic. This means that whenever I get ready to commit some business data to a database, I have to pass all of the business properties into the data method's parameter. For example:
Public Function Commit(foo as object) as Boolean
This works fine, but when I get into commits and updates that take dozens of parameters, it can be a lot of typing. Not to mention that two of my methods--update and create--take the same parameters since they essentially do the same thing. What I'm wondering is, what would be an optimal solution for passing these parameters so that I don't have to change the parameters in both methods every time something changes as well as reduce my typing :) I've thought of a few possible solutions. One would be to move all the sql parameters to the class level of the data class and then store them in some sort of array that I set in the business layer. Any help would be useful!
So essentially you want to pass in a List of Parameters?
Why not redo your Commit function and have it accept a List of Parameter objects?
If your on SQL 2008 you can use merge to replace insert / update juggling. Sometimes called upsert.
You could create a struct to hold the parameter values.
Thanks for the responses, but I think I've figured out a better way for what I'm doing. It's similar to using the upsert, but what I do is have one method called Commit that looks for the given primary key. If the record is found in the database, then I execute an update command. If not, I do an insert command. Since the parameters are the same, you don't have to worry about changing them any.
For your problem I guess Iterator design pattern is the best solution. Pass in an Interface implementation say ICommitableValues you can pass in a key pair enumeration value like this. Keys are the column names and values are the column commitable values. A property is even dedicated as to return the table name in which to insert these value and or store procedures etc.
To save typing you can use declarative programming syntax (Attributes) to declare the commitable properties and a main class in middleware can use reflection to extract the values of these commitable properties and prepare a ICommitableEnumeration implementation from it.