personally, I use ODATA in excel :) could work with PowerBI and other tools.
+1.
I would prefer more abstraction to avoid loosing too much time. (1 day for me) But I could understand that users needs to modify some parts. I'm sure i'll edit in the future some of this code, so if it's too abstracted, it will be more complicated.
and ... version 1.0 is out, which should be more stable.
all in all, i'm note sure if i want more abstraction or not. Could be great for migration, but also more difficult if I have to adjust this code to my needs.
there is some discussion on the forum about SP.
another subject : #446
I use SP & UDT without problem, in a custom repository with nuget specified in the following link
ok, i'll go for Something like /AppMain; thanks :mrgreen:
i didn't saw that it was already on the documentation :mrgreen: Well, that's not my creation, it's from another developer :oops:
it appears that : (source [https://coderwall.com/p/gvrn4w/update-all-nuget-packages-in-a-solution-matched-by-name]))
ForEach($project in get-project -all) { ForEach($package in Get-Package -ProjectName $project.ProjectName | ?{ $_.Id -like 'Abp*'}) { Update-Package -ProjectName $project.ProjectName -Id $package.Id;} }
is faster to execute than : (source [https://coderwall.com/p/wtobfg/update-all-nuget-packages-in-a-solution-matched-by-name--2]))
get-project -all | get-package | ?{ $_.Id -like 'Abp*' } | update-package
by avoiding unecessary check.
The complexity of the original one is too big as it tries to update all packages found for all projects, instead of just the packages present on each project.
the current one works fine, but i've already 28 projects in my solution, so it takes a lot of time ;)
to update all Abp* packages from nuget console :
ForEach($project in get-project -all) { ForEach($package in Get-Package -ProjectName $project.ProjectName | ?{ $_.Id -like 'Abp*'}) { Update-Package -ProjectName $project.ProjectName -Id $package.Id;} }
To close this subjet; I abandonned the idea of datetimeoffset in my db.
I converted every datetime in my db in UTC format and used the clock.provider like you said ("timing" in your doc).
datetimeoffset could be good to be stored; but not in my case anymore.
subject closed months after :mrgreen:
FYI, i created a console project to create multiple tenant at once.
my code look like this :
const string tenantConnectionString = "Data Source=XXXXXXXX;Integrated Security=False;User ID=XXXXXXXXX;Password=XXXXXXXX;Initial Catalog=XXXXXXXXX;";
var tenantId = _tenantManager.CreateWithAdminUserAsync("XXXXX", "XXXXXXX", "XXXXXXX", "xxxxxxxxxxx", xXXXXXX, true, null, false, false).Result;
SeedXXXX(tenantId);
protected void SeedXXXX(int tenantId)
{
using (var uow = _unitOfWorkManager.Begin(TransactionScopeOption.RequiresNew))
{
using (_unitOfWorkManager.Current.SetTenantId(tenantId))
{
var context = _unitOfWorkManager.Current.GetDbContext<XXXXXDbContext>();
new XXXXXXDbBuilder(context).Create();
_unitOfWorkManager.Current.SaveChanges();
}
uow.Complete();
}
}
yup, maybe I need to clean a little bit my code, i'm not yet a pro of unitofwork ;)
+1, i'm in the same case for a lot of table and I was going to ask the same question :D
For some tables, I use an unique PK which is not guid (for example a datetime or int; for optimisation/size purpose). Most of my case are separate databases with column TenantId set. But if I need to merge them into one db; TenantId will be correct but PK will be duplicated. (logic)
If I create a composite key (that's the only way I see ...), i'll rewrite a lot of code since almost all of my tables have IMustHaveTenant. And create a lot of DTO to remove the tenantId property.
But that's the only way that I see; so i'm going to go on this way.
Waiting for your reply/suggestions if you have another idea ;)
already discussed here <a class="postlink" href="https://github.com/aspnetboilerplate/aspnetboilerplate/issues/883">https://github.com/aspnetboilerplate/as ... issues/883</a>
right now, it still works even if it's marked obsolete :)