I'm starting a new project that uses couchbase (a noSQL database that stores objects in json format), together with php.
The thing is that it would be really easy to work with them both if I could have something that maps json into one of my own php classes (and vice versa).
Do you know any library for that?
One way to start is to look (or use) the "Basement" Library that is available here:
https://github.com/Basement/Basement
This library uses json_decode/encode.
Hope that will help you.
You may use our JSONmapper to map from JSON to your PHP classes.
It unfortunately does not support mapping back (yet).
Tug already mentioned Basement, which will provide that functionality of "models" in the near future like you know it from ORM systems.
Aside from that, mapping your plain old php objects to JSON is very easy, thanks to the nature of json_encode/decode. Since you can pass it an arbitary object and it will store it as JSON, thats basically the only thing you need at hand. If you need more infos about JSON and PHP, my blog post is a good start: http://nitschinger.at/Handling-JSON-like-a-boss-in-PHP
If you use Basement, it makes it a little bit easier for you since it allows you to transform PHP types into JSON behind the scenes automatically (or write your own mapper if needed).
If you have a specific example that you want to build, let me know and I'd be happy to provide an example!
Related
I have a PHP project which provides a api endpoint exposing JSON data. Part of that data are serialized strings generated in PHP.
In a nodejs application I can unserialize that data using the php-unserialize package. However, I am a complete beginner at Angular and can't find a similar package for AngularJS.
I would appreciate some direction on how to unserialize a string into JSON data in AngularJS
and, where I can find AngularJS packages?
The AngularJS framework does not have a service that decodes array and objects serialized by PHP serialize.
Instead encode using PHP json_encode.
I seriously recommend that PHP APIs avoid using serialize to communicate data.
From Anonymous:1
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.
The JSON Standard is well supported by most languages and widely used for data interchange on the Web. The AngularJS $http service supports it automatically by default.
I am working on making a search engine, I have to store multiple data against one word, how it will be done using php without use of JSON.
and is it a good approach to do this work in php or I should switch to another Object Oriented Programming Language ?
If its research project, you could give a shot with PHP7 (its faster). PHP5 will also let you achive what you want.
What language you chose is mainly dependand on what you want to achieve. C++ is surely faster than PHP.
Also you would need to check about bigdata handling and non-relational databases (MongoDB for example) which are scalable.
I was wondering what would be the best way to store JSON/XML responses. I'm currently building an application that supports heavily on the SoundCloud API to fetch songs/playlists etc.
Here are some ideas I've come up with.
Storing the results in a Relational Database and then using PHP to convert them to classes to make easy use of them throughout my application.
Doing the above, only this time using my framework's built-in ORM.
Using a Document-Oriented Database. (ie. MongoDB, couchDB, ...)
Storing the JSON responses in a cache. (using my framework's cache classes)
Can anyone care to shed some light on some of the advantages/disadvantages of using any of these methods?
Which one do you prefer?
If you have a solid schema, that you wont think it will change, you might want to use relational database. You will need to parse the json and make objects out of the JSON response and using your framework you can persist it to database.
If you think your schema will change use NoSQL.
It also depends what will you do with this data. Are you going to search the nodes within JSON?
You can also do a object to mongo mapping, you can either parse the JSON and store it as an object or you can store the JSON the way it is.
Nice thing about NOSQL is that they support JSON pretty well in which they use BSON (Binary JSON).
In terms of cache, IME, it should be used only for lookups, and actually, you cant search the cache. It s just for getting objects faster than going to database and getting it.
Take a look at this:
http://www.mongodb.org/display/DOCS/Inserting#Inserting-JSON
If you can tolerate hosting your music and playlist data on Google's AppEngine, Ubud-db can be something for you: https://bitbucket.org/f94os/ubud-db/wiki
Ubud-db is a document store on AppEngine with a REST-JSON API. Spring/Jackson maps from JSON to a Map, and then Ubud's service maps from the Map to Entity, persisted by the Datastore.
The REST-JSON API makes it easy to integrate with a website using AJAX to access and display dynamic data.
If I need keep the data for longer than a cache provider, I would store them in a database as-is and then just json_decode them when I retrieve them from the DB. If it's just temporary storage, cache is a great idea, still leaving it encoded as json to reduce the size.
I am planning and researching my switch from MySQL to MongoDB right now and I just had an interesting thought... I have a bunch of hierarchical objects that I need to store in the database. My current method is to have a bunch of embedded documents in a collection. They will never need to be searched for. Would it possibly make sense just to serialize the PHP objects, stick them in the DB, and then unserialize them back into PHP objects when I want to use them? The alternative is using Doctrine as my ORM.
My programming intuition tells me that this is bad design and is limiting, but I feel like serializing and unserializing would be very fast and eliminate the need for an ORM.
What's your opinion? Good design or bad design?
In many cases this would be considered bad design, but it could work if all of the following apply:
You don't need to search on them
You can accept (potentially) limited ability to query on them
You don't need relational integrity or other constraints enforced by the RDBMS
You know you'll never need to read them in a different language
You're confident that you'll know how to deserialize, version, and migrate them properly when you update your class definition
You're confident that the PHP serialization format will be stable across releases (or you are willing to write migration code, or it's a short-term project and you don't care)
You're willing to accept a minor performance penalty (SELECT + deserialize() will be slower than just SELECT)
Why use a database if you can't query it ?
It kind of depends entirely on what you intend to do.
If it's always the same object each request deals with or there are no relationships between each request, it might be ok.
But to me there are a lot of downsides:
You might want to do something more advanced to the objects later
Serialized objects are kind of unreliable (not exactly ACID compliant)
There's nothing else that can read a serialized php object, you might want to use something else instead.
Serializing objects is VERY useful when you have to cache things, such as RSS feeds.
I find it good use to serialize it, but I would also make sure that that can never be editing as a string without unserializing it first!
In my company we have developped some applications. We have to create an API for one application (say application A), so that the others can use it (an its data).
The question is : we already have developped PHP classes for the model of Application A, if we want to create an API, should we :
- re-use these classes (too much functionnalities for an API, too heavy...)
- create one PHP class, with some basic functions, that takes in input and returns only raw values (like strings, array... NOT complex classes)
- create another set of PHP classes, simpler, and designed only to be used by an external application (so only to get data easily)
Usually, an API is the 2nd solution (to be used as well with PHP than as a web service for example), but i find it too bad that we made a complex and usefull class modelisation, then we tear it apart just to have functions, strings and array.
The 3rd one seems to me to be the compromise, but a collegue of mine insist that this is not an API. Too bad...
What do you think ?
Solution number 3 might be the best one from an architectural point of view. Basically you are using a Facade Design Pattern to simplify your API. Since I am dealing with it at the moment: In Patterns Of Enterprise Application Architecture this approach is described as the service layer which makes totally sense since you don't want to expose any user (meaning whoever will deal with your API) to more complexity than is actually needed or desired.
This includes using the easiest possible interface and transfer objects (raw values if they make sense). As soon as your Facade is being called through remoting services (like a webservice) you will eventually have to break repsonses and requests down to raw values (data containers) anyway.
Build a set of Facade classes that simplify the public API.
Create some thin wrappers that implement simpler API over the original classes. DO NOT reimplement any business logic in the wrapper - that'd lead you into trouble if any of the logic changes, as you will surely lose track of which piece was modified and which was not. Keep the external inputs/outputs simple, if you need something more complex than string, use XML or JSON for structured data, but try to avoid too much complexity - if you have 2 things to pass two query parameters might be much better than one structure with 2 fields.
That's the 'Facade' pattern.
I would also say have a look at the Facade pattern.
Build a set of Facade classes that only offers the functionality that is really needed to be public. Those classes then for sure use your current core classes.
This gives you also the advantage that if you change the core classes, the API must not necessarily being changed.