We are working on a version of Sylius 0.9 in which we made several huge changes, overriding a lot of core logics.
Doing so we broke a bit the wired in logging or history functionality.
Lurking the code it looks like that this functionality is automagically working based on the Doctrine orm logging offered by the Gedmo bundle
It also looks like that this logging of any update to the model is declared in the models in the vendor.
My question is:
is there a way to disable this kind of logging?
It pollutes a table named ext_log_entries with around 1'000'000 records each week, which I'm manually truncating every now and then since we're not using this functionality and I don't want to have hundreds of MB in my DB for nothing.
Related
I have a large multi-tenanted Symfony2 application using doctrine and around 40 to 50 database tables in MySQL.
Has anybody had experience setting up an audit logging process for, at a minimum, tracking all Doctrine actions that create, edit or delete data in a large application?
Ideally it should "just happen" so that other developer don't need to worry about making their new entities or code "loggable".
I don't have specific requirements to meet (HIPAA etc) but it would be nice to be as close to any ISO27000 best practices as I can be.
My inital plan is to look at using some of the Doctrine lifecycle callbacks to grab the information and push it off into a a seperate MySQL database with no DELETE or UPDATE permissions. I'm concerned this method might have a big performance impact.
Has anybody done this before or anything similar that has any tips or words of warning abot my planned approach?
If it matters the whole stack is running on AWS and I can use any of their services in the EU-WEST-1 region. I am already using things like RDS, Elasticache and SQS.
Thanks!
OroPlatform is built in Symfony 2.8 and has a bundle called OroDataAuditBundle that audits all Doctrine entity operations (create, update, delete) at a deep level in just two tables: oro_audit and oro_audit_field.
And it looks like that in the UI:
You will not probably be able to use this bundle in your project - since it is built for OroPlatform - but, you could at least get some inspiration from their architecture.
If you want to check this audit system working, they have an online demo in https://demo.orocrm.com. Just log in as administrator and play around creating entries, and then you will be able to check all audit entries in https://demo.orocrm.com/audit.
We are going to build something like cratejoy.com, but don't want spend lot's of time building which is already builded before for developers.
I was going through sonata and sylius, but not sure if we can build subscription based model with one of them. If yes we can, then which would be best to use? or should we just build complete custom solution, because it involve b2b solution.
What we will be building?
Basically e-commerce software like any os-commerce shopping system, but the only difference is, we will be adding subscription on each product.
So let's say, if you order a product, we will ship it to you every month to your door step.
but we are building this as service, so many people can just create their site and start using our tools to start selling there products.
I might be a little biased towards Sylius, as I work with it constantly - I've tried using Sonata bundles in projects before but failed in making use of them.
Reasons for using Sylius are that it's heavily decoupled and customizable, which is exactly what you want if you need an e-commerce solution that is not the conventional "add product to basket, pay for it once" model.
There are two approaches you can take to use Sylius: Either use the full stack application and customize it, which is the most common approach and better supported. The other approach is to install Sylius like a library rather than an application and build the application and frontend yourself, using Sylius classes and services when you need to (which is what I do).
Things to be careful when using Sylius are that it's still in beta, with breaking changes occurring between releases. Also the documentation is very incomplete or outdated (something I plan to help improve), with the exception of Resource and ResourceBundle - these packages are the most important part of Sylius and are therefore very well documented. For your project, I recommend the first option.
For subscriptions, areas of Sylius you want to look at configuring and extending are OrderBundle, PricingBundle and PaymentBundle. If you're very familiar with Symfony, this should be straightforward.
We're planning a new intranet for our organization. Some part is like a CMS, and there are some custom-made applications.
The Symfony2 CMF distribution looks fine for building the CMS part of the intranet, but other parts like Doctrine, "normal" SQL databases, etc, looks better for the custom-made applications for the intranet.
Because I need common authorization and authentication system for this intranet (against an Active Directory), I supose that I'll get better results building all in only on app. So, can I mix a CMF application with a normal application, and both use the same database (an Oracle DB)?
Yes you can easily mix the CMF with other Bundles. For example the routing allows using both routes from the CMF as well as "static" routes defined in yml files. Also you can easily also add the ORM next to PHPCR ODM. If you use Doctrine DBAL for storage in PHPCR, you can even reuse the same connection configuration with the ORM etc.
In brief yes it is, and I do this in my own Symfony2 project. I combine both SF-SE and SF-CMF bundles.
In fact, with Symfony2 it's very simple (this is just a matter of choosing the most suitable Bundles; SF is a very decoupled framework, which is why I don't plan to migrate to any other solution for the moment), but I'd like to share some of my experience with doing that. Actually the one most important question to think through to make a decision about how to combine both "worlds" is this:
Composer.
After some inquries I found out that since Symfony CMF is (in a way) based on Symfony SE, and not vice versa, it's better to start with the latter, as it contains the most core features (though I did it also in the opposite way, rather not recommended). So just take a SF-SE's composer.json, take a look at bundles from there you need, and then take a look at differences within SF-CMF's composer.json. You should end up with the most suitable set of bundles.
The basic features from these bundles to look-up for are:
MODEL - Doctrine ORM, PHPCR-ODM, or both - if still not sure, don't hesitate to ask a comment, I'll share here my experience furthere.
ROUTING - the primary question here is how flexible routing do you actually need? If not sure, I'd go with standard SF Router, and then possibly replace it e.g. when still on a dev stage.
OUT-OF-THE-BOX CMS FUNCTIONALITY - bundles such as CreateBundle, MenuBundle or MediaBundle may help you building surprisingly fast, but not quite flexible soltions. In general, I ended up without using most of them, and if using, then I mainly take some Interfaces I do implement in my own Bundles (to ensure future compatibility with possible other bundles to be potentially used).
Besides of these above, I created a number of Bridge Design Pattern and Provider Design Pattern solutions to make some bundles working together, to adjust their functionalities, or simply to decouple things.
In programming almost everything is possible. But think about restrictions delivered with CMF (routing for eg.).
Maybe you should consider Standard Symfony with Sonata? I think CMS pages it's only small part of your system and implementation it in standard symfony will take smallest part (and cost) of whole project.
Is it possible to build an ASP.NET website using EF where each customer logging in has separately stored data? We have customers demanding that their data won’t be stored in the same tables as other customers’ data.
I’ve read that EF can’t work with several databases but is it possible to switch database at runtime depending on input parameters? I have a feeling it won’t be possible since the migration features are tightly connected to the database being used, but I'm not sure.
One solution could be to have a separate website deployment and database for each customer. They’ll get separate domains to access but that’s not a problem. But this solution feels a bit clumsy if you’re having many customers, especially with deployment and future upgrades.
Am I missing some smart ways of solving this or is this a very tricky issue?
is structure (of the db) the same ?
if so you could switch connections - not w/o issues though, but should work. For details on how that should be done check the long discussion we've had here (and linked previous questions etc.)...
Code first custom connection string and migrations without using IDbContextFactory
I'm new to version 2 of the Symfony framework. I made some projects with v1 but now trying to get my head around the new version and it's features.
I read over the concept of Bundles but it's purpose is not yet very clear to me.
Say you have a big web application, a CRM for example. How would the bundles look like?
Would it be NewsletterBundle (for sending newsletters), ContactManagementBundle (for managing contacts), UserBundle (for editing users and their permissions).
Or would it be less cut-up like, EmailBundle (for handling the entire email traffic), CRMBundle (for putting in all your CRM code), PermissionsBundle, ApiBundle.
I like to think of it like this: a bundle should represent a specific feature or set of like features for a project.
Your first example is a better use of bundles than your second example, because the purpose of each bundle is more defined. While it's possible to use one CRMBundle for everything, you wouldn't really be taking advantage of Symfony's ability to organize your code. Additionally, if you wanted to port over your Newsletter code to a new project, but not all of the CRM code, you'd have an easier time copying over a NewsletterBundle versus copying over the CRMBundle, and then pruning it.
When thinking about a Symfony2 project, sometimes you want to forget everything you know about symfony 1.x, since they take wildly different approaches to solving many problems. For example, in symfony 1 it was common to build a 'frontend' and 'backend' app for a project, and each app would obviously contain logic specific to those parts of the project. So you might have a Newsletter controller in both the frontend and backend apps. In Symfony2, you're better off using only one Newsletter bundle, but with two controllers (perhaps named 'frontend' and 'backend'). Again, an immediate benefit to this is how reusable your code becomes.