I have an Article and Comment entity (oneToMany)
On Comment prepersist lifecycle event I would like to count how many comments there are for this article and update Article's comment_count field.
If I understand symfony2 approach correctly, I need to write a service for this. Let's call it CommentCountManager.
My question is: How exactly do I make container available in entity so that I can get the CommentCountManager and triger the funciton that count comment for given article, and how do I access Doctrine's entity manager in my CommentCountManager so that I can actually run queries there?
Am I on the right path?
Your help is greatly appreciated.
You don't need to store the comments count in a separate column — you can count them on output. What you are trying to do is denormalization and I recommend avoiding it unless you absolutely need it for performance reasons — and only when you are sure that that part is causing the problems. But even then, query optimization and caching are much better alternatives to denormalization.
Making entities aware of the container is a bad idea too. If you need this, then you are doing something wrong.
To access an entity manager in a service, you need to inject it.
Related
I know automatic insertion happens to domainevententry table as soon as we do aggregatelifecycle.apply(event) in axon framework what action triggers an insert in domainevententry table and what triggers a publish to a kafka topic in axon framework and how can we control what values goes into domainevententry table
Explaining this point by point, in full detail, would be a bit much to go over.
On top of that, like #Pipetus stated, it is still unclear what your intent is with this question. It's highly recommend to be as specific in your posts as possible, stated the problem space, where you are coming from and where you want to get too.
Regardless, pointers you can look for when it comes to "how does this work" are the (aggregate) Repository implementations, the options of EventStorageEngines provided, the UnitOfWork used to deal with message transactions and the phases the UnitOfWork transitions.
In short, all of these are described in the Reference Guide of Axon. I'd recommend reading up here and updating your question accordingly so that more specifics can be provided to you.
The MS Graph API has the possibility to list the direct members of an AD group using
/groups/{id}/members
Is there a way to get both direct and indirect members, i.e. member of members of members and so on and so forth.
I would like to avoid the need to implement some recursive logic on the client if it can be done another way, possibly through the use of OData query parameters?
I have tried the following using $expand and $level, but unfortunately the 'members' navigation property doesn't exist on the child groups for some reason and I guess that's why they are not expanded.
https://graph.microsoft.com/v1.0/groups('{group-id}')?$expand=members($levels=max)
Unrelated to the question, could someone with the necessary SO permissions please make the ms-graph and the microsoftgraph tags synonyms?
Update: The feature request mentioned below is in beta now.
I found a feature request on uservoice.com for this, so it seems like it does not exist yet. If you came here looking for the solution, I encourage you to go and vote for the feature.
I'm creating my main project functionality right now so it's kind of a big decision to make in my project, I want efficient & scalable solution. I use different API's to fetch users products ultimately for 1 collection to display products information inside a table with possible merge by SKU TITLE from different sources.
I have thought of 2 approaches (In both approaches we add Meteor.userId() to collection insert so each users has it's own products:
1) to create each API it's own collection and fetch the products to it, after or in middle of the API query where I insert it to sourceXProducts also add the logic of merge products by sku and add it to main usersProducts Only the fields I need, and we have the collection of the sourceXproducts if we ever need anything we didn't really include to main usersProducts we can query it and get it so we basically keep all the information possible (because it can come handy)
source1Products = new Meteor.Collection('source1Products');
source2Products = new Meteor.Collection('source2Products');
usersProducts = new Meteor.Collection('usersProducts');
Pros: Honestly I'm not sure, It makes it organized also the way I learned Meteor it seems to be used a lot.
Cons: Meteor collection joins is not supported in core yet, So I have to use a meteor package such as: meteor-publish-composite which seems good but this way might hit performance
2) Create 1 collection and just insert everything the API resonse has and additional apiSource field so we can choose products from X user X api.
usersProducts = new Meteor.Collection('usersProducts');
Pros: No joins, possibly better performance
Cons: Not organized, It can become a large collection maybe it's not good for mongodb
3) Your ideas? :)
First, you should improve the question. You do not tell us anything precise about your schema. What are the entities you have and what type of relations are there and what type of joins do you think you will be doing. How often you will be doing them?
Second, you should rethink your schema and think in the terms of a non-relational database. I see many people coming from SQL world and then they simply design their schema in the same way. Wrong. MongoDB is not SQL and things you learned there you should not try to just reuse here. You should start using features like subdocuments and arrays which can help you solve many basic things you would do in SQL with joins. So, knowing your schema would help us help you design the schema. For example, see this answer and especially the comments for the discussion for a similar type of question you are asking here.
Third, have you evaluated various solutions which exist out there? There are many, but you have not shown us that you tried any of them and how it worked for you. What were pros and cons of them, for you and your project?
Fourth, if you are lazy to evaluate, you can just use peerlibrary:peerdb and peerlibrary:related. They are simply perfect. You should trust me. I am their author.
I have an entity (eg Image) which is related to many other entities (eg Product or Category). I would like to know which is the best way to prevent the removal of an entity if a relation exists somewhere else (eg I should not be able to delete an Image if it is related to a product). My thoughts are either searching for relations in a repository class and returning results, or doing 'something' at the preRemove lifecycle event of the entity. Which is the best Symfony2 way for preventing removal of related entities?
As long as cascade delete is not set, any directionally entity will prevent delete of the related entity. If your associations are not birectional, you'll have to query form the backside as well.
To expand upon CJ's answer, you may remove delete links, but you will also have to check the entity in controller as well, because any url hacker can delete an object if its id is known.
What I would suggest is you can better of disabled the form delete link when there is a relationship between entities. In that way you can even make the customer understand that there is related entity and he should not remove it before removing the relationship.
You can always check the entity before deleting it and when you actually call certain process in symfony on an entity you actually work on the entire object of that particular entity which gives access to all the values of that entity. So you can check it at that particular point and make conditional statement.
It my personal believe that you should not try to import excess library functions for minor things which can be achieved by you without them. this would make you code easier to understand and even lighter as the prospect for including extra libraries which will most likely have more than what you need
http://www.silverstripe.org/archive/show/1638
The above post seems like it's what I should do but I just need some help sorting this out in my head.
Firstly, I need to create a relationship between a page (Owner, for example) and a dataobject (Car). An owner can create many cars which are linked to that one owner. However, I have another page (Garage) which can create cars that are linked to every owner. If an owner does not want one of these cars they reject it. I was thinking the manymanydataobjectmanager would be good for that bit.
Each owner should only be able to see the cars that relate directly to them within the CMS, not other peoples cars, so I was using dataobjectmanager and assigning permissions to the page using groups.
The thing that is really making this awkward is that when it's all set up I need to output JSON which will consist of the cars the owners created and the cars they accepted from the garage, not the ones they rejected. I'm thinking I need another table like the linked table but with a status column perhaps?
To clarify, my question is how do I create this mess in a constructive SilverStripe way? Is the approach I was taking correct or is there a better way?
Many thanks in advance and please tell me if I've been unclear.
are you using silverstripe 3?
could you clarify what of the actions happen in the backend and what actions are possible for the user in the frontend?
maybe for your relations it could be better to use ModelAdmin:
http://doc.silverstripe.org/framework/en/reference/modeladmin
It gives you the opportunity to manage relations without the Sitetree/Pages Overhead. For example creating a Sitetree Element just to have an Owner is not the best way - except if you really need an Owner represented as a real Page. Owner could be also just a Dataobject instead.
Especially if you want to output just JSON in the end you are maybe completely independent of Sitetree/Pages... then you could write a custom controller with a routing rule and which gives you back just the data that you need:
http://doc.silverstripe.org/framework/en/topics/controller
regards,
Florian