I have an existing .NET application where most of the variables are stored using MemoryMappedFIles.
I am merging this now existing php functionality.
The porblem is now how to access the .NET variables from within php.
My current solution is based on implementing a pipe between both environments, but this does not hold when the load is high. Also, it is difficult to exchange structured data. I could try a relational database or a file in between, but this obviously adds overhead.
Any ideas on how to expose .NET variables into php ?
thanks.
May be its not a good idea. Can you store those memory mapped variable value into cookies and
you can access those value using PHP cookie variable .
eg. $_COOKIE['variable name'];
If variables are going to be used across environments then a shared data store would be a good solution. I do not know too much about .NET variables, and how one might expose them, but it sounds like it might be a bad idea, or at least a hassle.
When sharing data across environments the idea is to think of the data as being stored in one central place:
[.NET] [PHP]
\ /
|
[Data]
This architecture is good because you keep stuff separated, which means that each component can be handled (i.e. optimized and scaled) individually. It also means that you can swap out, or add, components. For example, if you in a month decide to hire a group of Ruby developers to build some project then they will not have to worry about the other languages, they just need to connect to the data store and run with it.
As for what data store to use, it does not have to be files or a relation database; depending on the kind of data, you can use in-memory key/value stores like redis or memcached, or if the data is more structured then maybe a document database like MongoDB would fit better.
Related
I came across an interesting comment in php.net about serialize data in order to save it into the DB.
It says the following:
Please! please! please! DO NOT serialize data and place it into your
database. Serialize can be used that way, but that's missing the point
of a relational database and the datatypes inherent in your database
engine. Doing this makes data in your database non-portable, difficult
to read, and can complicate queries. If you want your application to
be portable to other languages, like let's say you find that you want
to use Java for some portion of your app that it makes sense to use
Java in, serialization will become a pain in the buttocks. You should
always be able to query and modify data in the database without using
a third party intermediary tool to manipulate data to be inserted.
I've encountered this too many times in my career, it makes for
difficult to maintain code, code with portability issues, and data
that is it more difficult to migrate to other RDMS systems, new
schema, etc. It also has the added disadvantage of making it messy to
search your database based on one of the fields that you've
serialized.
That's not to say serialize() is useless. It's not... A good place to
use it may be a cache file that contains the result of a data
intensive operation, for instance. There are tons of others... Just
don't abuse serialize because the next guy who comes along will have a
maintenance or migration nightmare.
I would like to know if this is a standard view about using serializing data for DB purposes. Meaning if it's a good practice to use it sometimes, or if it should be avoided.
For example, I was instructed to use serialize myself recently.
In this case the data we had to save into a MySQL table was the following:
Car brand.
Car model.
Car version.
Car info.
Car info was an array representing all the properties of a version, so it was a large variable amount of properties (under 100 properties). This array was the one to be serialized.
The main reason I was given in order to use serialize was the following:
Being a large number of fields, it is better to serialize the data in
order to improve performance instead of creating a field for each property
or multiple tables.
Personally I agree more with the commentary in php.net than with this last asseveration, but I would like to here more qualified opinions than mine about this.
Being a large number of fields, it is better to serialize the data in
order to improve performance instead of creating a field for each
property or multiple tables.
I would consider this highly dependent on the use case. What if there is a class Customer that wants to have infos about all cars that are running Diesel or any other specific data for the car (using fuel seems easiest). You would need to get all the cars from the database, unserialize it, check for the propery and keep the list with all cars relevant for the customer.
Example: We had to move some person-related data from an old customer CMS to a new one. Instead of having each attribute nicely mapped on the database, the whole information was a single string in the old database. So instead of using a proper database structure, we had to do lots of regex-foo to turn the data into a proper structure again. Of course, this was an expensive (both monetary and work-load) task. In this case, the problem was not that huge since the amount of data was managable. But imagine the same scenario with millions of rows and more than just a single string....
The comment you posted is only talking about data structures IMO. And I agree, storing these is not very good nor efficient. It will be much easier to have a typo somewhere or add a new property that other parts of the language are not aware of. This WILL leed to problems sooner or later.
On the other hand, storing some configs that are more easily ported might be an OK case for serializing data. You could argue that there external setting files are more ideal for such a case, but this will be highly dependent on the case/philosophy/customer/...
TL;DR
In most cases, using a proper schema will sooner or later benefit the whole development, speed wise and complexity wise (since I preferr reading many table descriptions instead of a huge, cryptic string). There might be some use-cases where serializing data is acceptable so giving a finite answer if this is good or bad practice is not that easy and highly dependent.
What I have been able to grasp from reading the source and documentation from several PHP frameworks is that they generally don't persist, except for what you personally cache or throw into a $_SESSION var. Why is this? It seems a waste to essentially initialize the framework for every single request, would it not be better to at least serialize and store some core objects and variables to save processing and time?
At first I thought this was rather subjective and avoided asking, but everything I've read doesn't really speak about it at all, so there must be something obvious I'm missing.
The only real mention/discussion I've found of this is here which doesn't directly answer my question and some of which goes over my head a little.
Edit for Clarification: I am not asking about the inner workings of PHP, I know how persistence works (ie won't persist unless you make it through caching or session vars), I am asking why PHP frameworks don't do this for their core objects. Again it seems subjective to me, but as almost nothing I've read mentions it, and it seems to be fairly standard practice, I'd like to know what I'm missing.
Memory:
Most frameworks don't store these core mechanisms in $_SESSION due to memory concerns. Frameworks often generate variables / objects that can contain several megabytes of information. That may not sound like a lot, but scale that to a few thousand users and you've got a problem.
Data "Freshness"
The second issue with shoving framework components into memory is that they can become out of date very quickly. Instead of pulling an object out of memory, checking to see if it's outdated and then recreating it (if it's indeed outdated) is less efficient (most of the time) than just recreating it with every request.
I hope this clarifies things.
If you want data to persist between server requests then you need to use cookies/sessions or store your data in a database. This is just the way that it works. PHP cannot store data in itself for use between server requests.
Some frameworks may store core objects in a database or to a local file on disk, but it would depend on the framework.
I'm new to OOP using PHP and the idea seems a little pointless in some ways. In non-webbased languages the object lives through-out the life of the program (from execution to exit). In this situation it make perfect sense because you build the class then initialize it at run-time where you can access it frequently as needed there after. However with web programming since the execution of an application might happen in many stages (page loads) the life of the object could end up being only a small portion of the time an application is being run. So it seems to me that the only option to keep objects alive during the course of the application's usage would be to store that object after initialization in a session variable. Is this common practice or are there other means by which to utilize the power of OOP in PHP more effectively?
PHP's website has an article that deals specifically with this: Serializing objects - objects in sessions. There's absolutely nothing wrong with serialize objects in your session but as this article suggests:
It is strongly recommended that if an
application serializes objects, for
use later in the application, that the
application include the class
definition for that object throughout
the application. Not doing so might
result in an object being unserialized
without a class definition...
It can still be very useful to manage objects with short, time-limited lifespans. Perhaps you want to communicate with two different kinds of database servers -- having objects that know how to build queries for those database servers can be very convenient. You, the programmer, get to interact with them in the same way, but behind the scenes one might use a unix domain socket to talk with a local PostgreSQL and the other might use a TCP connection from a session pool to talk with an Oracle instance.
Object-oriented programming exist to provide encapsulation and abstraction. Both are useful, even if the objects involved are created, live, and die, in .5 seconds.
With PHP you cannot keep an object alive, so you cannot store it in the session to gain performance. PHP will always serialize the object when writing to the session and deserialize it reading from the session.
To answer your question, yes it's very common to store an object in a session, but not for performance reasons. Storing and reading from the session are quiet fast, so i would only look for optimizations there, if you are sure this is a bottleneck.
Somethings to make sure you do if you take this approach is make sure your garbage collection is thoroughly working. Depending on what the object does it may store as quite a large record in which case you will be taking up quite a bit of disk/database storage.
I am a Codeigniter fan but those objects are huge and it would be highly unwise to store them. Security is another factor - if you are on a shared server and there is a chance of security credentials being held in the object then storing these may also be unwise.
I do store objects in a database but just make sure Garbage collection is working. If you use a database there is a bug in Ubuntu where the collection doesn't run - in which case you need to force it through ini_set.
I'm writing a web application in Symfony for the first time, so I have a question regarding the use of Doctrine vs. Stored Procedures.
My background is in Java server-side, so I wanted to know what the pros and cons are for using stored procedures, versus using simple Doctrine code to get things done. At the most basic level, let's say that my Symfony web application is used for management, while there's another engine (which might or might not be written as a Symfony component, or indeed not in PHP at all) which retrieves configurations from the database for distribution or whatnot. Here I can see where stored procedures might be handy: both code bases use them to query and access data, while neither are preoccupied with the actual schema. If there's a change to the schema (adding a column in some table, for instance), then I'd only have to change the SRPOC, and nothing else, whereas if I had been using code in both engines to access data, I'd have to change them both to match the new schema.
Any comments? Or did I take it too far?
Thanks!
-DBG
If you don't use doctrine, you loose database abstraction, and object mapping. And this is a major loss. If you need third party apps integrations, you shouldn't let them interact with your database. Rather, provide a web service for them to read/write data via JSON, for example. This way you can change your database schema and have control over third-party apps.
Is there a standard way of dealing with globally scoped variables in PHP? Session scoped?
From the research I've done, it looks like the options are mostly add-ons or external. APC might work, but would be limited to a single PHP instance and not so useful for a farm of servers. Memcached seems like it would work, but I was hoping to find something within PHP.
Does its stateless approach keep there from being a standard method for handling this?
A persistent layar is the only way to go with php. Either file based solution or database.
php natively doesn't provide any mechanism to do application scope variable.
You can do session variables with $_SESSION.