In my code base, I have several variables that "live" in the main namespace and various modules I utilize can expect to always find in main (for example, $main::author is a reference to a hash about the user, $main::dbh is the open database handle, $main::loader is an object of a core utility class and $main::FORM has the processed QUERY_STRING). E.g. when the program starts up:
$main::author = &getAuthor;
$main::loader = SAFARI::Loader->new;
use SAFARI::View;
my $view = SAFARI::View->new;
$view->output;
And then when I'm in SAFARI::View::output, I can call on those core variables, e.g.:
# Display user name:
$output .= 'Hello, ' . $main::author->{'fullName'} . '! Welcome!';
The problem: when the code is running in a threaded environment, one thread may need a different $loader object or have a different $author logged in than the other thread. More pressingly still, each thread has, of course, a different database handle.
I know I could pass along the core information when creating objects such as View by adding parameters it takes. But that means every type of object that presently can just reference these items in the main namespace must have a lengthy list of parameters instead. I'm trying to think of the most efficient and "safe" way to solve this problem.
I've considered creating a hash reference that has all the different bits in it within each thread, e.g. $common that has $common->{'FORM'}, $common->{'loader'}, $common->{'author'}, etc., and then pass those as a single argument to each object:
my $common = #Logic to set up this combination of bits for this particular thread.
my $view = SAFARI::View->new({ 'common' => $common });
my $article = SAFARI::Article->new({ 'common' => $common });
my $category = SAFARI::Category->new({ 'common' => $common });
That's not too tedious, but it still seems inefficient; it'd be preferable if the "environment" of just that thread could contain something that object within in it could access. As far as I can tell, declaring our $common within the subroutine that is run by the thread would do this and any objects created within that subroutine would have access to that variable. Is there any harm in this approach?
It seems like it would be cleaner to have these items in some sort of namespace, but if I refer to, say, $SAFARI::common, that name space would reach across threads just like main does. Would having $SAFARI::common but then declaring a local variant of it in each thread be reasonable?
Is there a "best practice" for what I'm trying to do? It's going to take some significant reworking of code to fix this one way or another, so I'd really like to get it "right."
This is a complex question, with multiple major components.
For starters, there is a question of how to pass an initial data-structure to threads so that they can use it, but without it being shared.
In Perl, when threads are created the existing data are copied to each thread. That's why it's often a good idea to create threads right up front, before there's much data in the program, to avoid those threads being bloated. The copied data is not shared, by default, in Perl.
So you can just create your initial $common structure in the main:: and then create threads, and each will get its own copy of it. Then threads can create their own SAFARI:: objects and do as they please with the data structure. A simple demo
use warnings;
use strict;
use feature 'say';
use Data::Dump qw(dd pp);
use threads;
my $ds = { val => 10, ra => [ 10..12 ] };
my #threads = map { async(\&proc_ds, $ds) } 1..3;
$_->join() for #threads;
say "main: ", pp $ds;
sub proc_ds {
my ($ds) = #_;
# Modify data in the thread
$ds->{val} += 10 * threads->tid;
$_ += $ds->{val} for #{$ds->{ra}};
say "Thread ", threads->tid, ": ", pp $ds;
}
This prints
Thread 1: { ra => [30, 31, 32], val => 20 }
Thread 2: { ra => [40, 41, 42], val => 30 }
Thread 3: { ra => [50, 51, 52], val => 40 }
main: { ra => [10, 11, 12], val => 10 }
If, instead, you need to share data structures perhaps see this page, for example.
Each thread then needs to use a class hierarchy, whereby multiple subclasses should be initialized the same way using a common data structure modified in each thread.†
In Perl's inheritance model, methods gets inherited from the parent class but not data. So the question here is how to nicely populate all subclasses to same data.
There are advanced techniques that may make the process more elegant, but I'd suggest to simply introduce the attribute and define the method in the parent class and then have all subclasses use it to initialize. That is going to be crystal clear, and as economical as anything else. Like
use SAFARI::View;
use SAFARI::Other;
# ... set/customize $common
my ($sview_obj, $sother_obj) =
map { $_->new->init_common($common) }
qw(SAFARI::View SAFARI::Other);
say "View object: $sview_obj"; # overload "" (quotes) for this, see below
This would be done in each thread, where $common is first customized per thread as needed.
There isn't a magical way for the derived classes to pick up data from the parent, and you don't want a base class to have to know about its derived classes, in principle. And there is nothing wrongjk with nicely instantiating all subclasses, much like in the question itself.
The sub init_common need only be defined in SAFARI, the parent class
SAFARI.pm file
package SAFARI;
use warnings;
use strict;
sub new {
my ($class, #args) = #_;
my $self = {
common => {}, # introduce the attribute, for clarity
# ...
};
return bless $self, $class;
}
sub init_common {
my ($self, $data) = #_;
$self->{common}->{dbh} = $data->{dbh}; # etc, populate common
return $self;
}
...
1;
We don't need to specify the attribute in the constructor if it's not being set as it will be created by writing to $self reference in init_common, but listing it helps clarity. (Of course, common attribute can be written at construction ‡ as well; and, we don't need a separate method for it either.)
Derived subclasses need not mention any of this, attribute nor init_common method, unless they should customize things.
SAFARI/View.pm file
package SAFARI::View;
use warnings;
use strict;
use feature 'say';
use Data::Dump qw(pp);
# Make sure #INC gets set as needed
use parent 'SAFARI';
use overload ( q("") => sub { return pp {%$_[0]} } );
# no need for init_common, nor for new (except to modify/override)
sub output {
my ($self, #args) = #_;
say $self->{common}->{...};
return $self;
};
...
1;
† Inheritance is already in place here, otherwise composition or roles would be good alternatives. Even so, still consider using a role here; see this post for instance.
‡ If 'common' data can be passed to the constructor
sub new {
my ($class, $attr) = #_; # pass a hashref with attribute => value
my $self = {
common => {}, # introduce the attribute, for clarity
# ...
};
bless $self, $class;
$self->init_common( $attr->{common} ) if exists $attr->{common};
return $self;
}
sub init_common {
my ($self, $data) = #_;
$self->{common}->{$_} = $data->{$_} for keys %$data;
return $self;
}
then 'common' can also be initialized as
# ... set/customize $common
my ($sview_obj, $sother_obj) =
map { $_->new( { common => $common } ) }
qw(SAFARI::View SAFARI::Other);
I have a ReactiveObject with a Property "A" of type "ReactiveList".
In my ViewModel I'd like to sum a property of "T" of every item in my list.
I got it working, while "A" not changes its value.
But all gets "out of sync", when I assign a new value to "A" (e.g. this.A = new ReactiveList();).
Does anyone have an idea how to solve this? I hope I explained my problem clear enough.
Instead of listening to A directly, listen to this:
this.WhenAnyObservable(x => x.A.ItemsChanged).Subscribe(...);
Whenever A changes, you'll resubscribe to A. Now, knowing when to reset to do a Sum, that's a bit more tricky. Here's the lazy yet more fool-proof way to do this:
Observable.Merge(
this.WhenAny(x => x.A, _ => Unit.Default),
this.WhenAnyObservable(x => x.Changed).Select(_ => Unit.Default))
.Select(_ => this.A.Sum(x => x.SomePropOnTheItem))
.DistinctUntilChanged()
.Subscribe(x => Console.WriteLine("Latest sum is {0}", x);
1 - I'd avoid assigning new Collections continuously as part of your logic, and rather use Clear(). Which should have the same impact in terms of GC.
2- If absolutely necessary, utilize a SerialDisposable and subsribe on the main object A
this.ObservableForProperty(p=> p.A).Subscribe(newAvalue=>{
someSerialDisposable.Disposable=
newAvalue.Changed.Subscribe(_=>this.Result=this.A.Sum(x=>x.T))
});
This would dispose previous deep subscriptions on A instances.
This code works but I would like to know whether this is good solution? Would this solution using Expression Tree be considered better than Emit and OpCodes?
var target = Expression.Lambda(
Expression.Block(
new ParameterExpression[] { },
Expression.Call(
typeof(MessageBox).GetMethod("Show", new[] { typeof(string) }),
Expression.Constant(1.ToString(), typeof(string))
)
),
new ParameterExpression[] { }
);
AssemblyName aName = new AssemblyName("DynamicAssemblyExample");
AssemblyBuilder ab =
AppDomain.CurrentDomain.DefineDynamicAssembly(
aName,
AssemblyBuilderAccess.RunAndSave);
ModuleBuilder mb =
ab.DefineDynamicModule(aName.Name, aName.Name + ".dll");
TypeBuilder tb = mb.DefineType("MyDynamicType", TypeAttributes.Public);
var method = tb.DefineMethod("dynamicMethod", MethodAttributes.Public | MethodAttributes.Static);
target.CompileToMethod(method);
The code in your example seems like just "example" code. I don't see it as requiring expression trees. If I read it correctly it is merely creating the constant expression () => MessageBox.Show(1.ToString());.)
Expression trees are great, among others, when actual dynamic code needs to be created i.e. when interpreting some other language within a program or for operations that would otherwise require reflection (e.g. in programs such as Automapper.)
Are they better than emitting the op-codes directly. It really depends: can do a better job than the compiler? Emitting op-codes is like writing assembly, it is time consuming and you really need to know what you are doing to be able to write optimal code. Is the performance difference between compiler and hand optimized code worth the extra effort?
So my friend and me were discussing on whether to use object or id in DQL
I searched on internet but I couldn't find anything in doctrine documentation to see which is the best practice
So the problem is like this
Imagine you have the Category object
You want to get the products that have the price less than 10 so for better performance you make a DQL in the product repository and pass the $category object
My friend says we should pass $category->getId() and search by Id like this
public function findCheapProducts($categoryId){
return $this->createQueryBuilder('p')
->where('p.category = :categoryId')
->andWhere('p.price < :price')
->setParameters(array(
'categoryId' => $categoryId,
'price' => 10
));
}
But what I say is like this
public function findCheapProducts(Category $category){
return $this->createQueryBuilder('p')
->where('p.category = :categoryId')
->andWhere('p.price < :price')
->setParameters(array(
'categoryId' => $category,
'price' => 10
));
}
I wrote the code here so the error or things doesn't really matter to me here
The objective is to see which is the better way to put a condition by the identifier
I'm mixing both depending on the user input. When I already have the object I pass it, if I only have the ID like after a form submission I pass the ID as it would be nonsense to load the model just to pass it to into the querybuilder. (ofc. you need a proper form validation in this case to avoid wrong IDs)
We are using accountability pattern for organizational structure. I using linq to nhibernate to find some departments and position but I have two problem.
var query =
Repository<Party>.Find(p => p.IsInternal == true)
.Where(p => p.Parents.Any(c => c.Parent.PartyId == id))
.Where(p =>
(
p.PartyType.PartyTypeId == (int)PartyTypeDbId.Department &&
_secretariat.Departments.Select(c => c.PartyId).Contains(p.PartyId)
)
||
(
p.PartyType.PartyTypeId == (int)PartyTypeDbId.Position &&
p.Children.Any(c =>
c.AccountabilityType.AccountabilityTypeId == (int)AccountabilityTypeDbId.TenurePersonOfPosition &&
((Person)c.Child).UserName != null)
)
);
First : I got 'Unhandled Expression Type: 1003' for this part of query : '_secretariat.Departments.Select(c => c.PartyId).Contains(p.PartyId)'
and I got Property not found 'UserName'
We have many complex queries i think we need to use stored procedure.
Sorry for bad Inglish!
One nice thing that you can do with LINQ is break your queries into multiple parts. Since you are building an expression tree that won't get executed until the results are enumerated, you don't have to do it all in one line (like SQL).
You can even make some reusable "filters" that you can apply to IQueryable. These filter functions accept an IQueryable as an argument, and return one as a result. You can build these as extension methods if you like (I like to).
As for your immediate problem, you may want to try a join on _secretariat instead of attempting a subquery. I've seen them work in scenarios where subqueries don't.
In addition to Lance's comments you might want to look at a compiled Linq query and breaking up some of the responsibilties to follow SOLID principles.
I've just also found out that there are issues with the Contains when containing Any linq methods. However, Any seems to work well within Any, hence:
_secretariat.Departments.Select(c => c.PartyId).Any(x => x == p.PartyId)