I'm preparing laboratory script for presenting features of of OCB, however
there is a misconception on how OCB references to Data Models defined by
FIWARE. I'm aware of parameter 'type', which is supplied along with new
entity. The problem is connected to OCB. How does it difference between data models?
I can add variables from different data model which don't match. I
can't find the controller for it and if there is no any that's really shame. The problem I got is connected with situation:
Creating entity with declared type for instance: Device
Adding some parameter, which is not specified in Device schema. It could be dateLastWatering from Garden data model.
It doesn't make any sense, how the OCB reacts to that?
From my experience it just "swallows" the updated content as long as semantic of command is correct.
I received information that a restriction can be implemented in application layer, however in my opinion it should be supplied along with OCB already.
That way model can be mistaken and the example is not really educational. It
could be useful if after defining a model for entity, OCB could interact
somehow with user and check, or debug what it receives. That way it would be
more professional I guess and fore sure more safe to use. If OCB doesn't have
that feature is there a possibility for further development?
Orion Broker is totally agnostic with regards to Data Models. Orion is not intended to check schemas or perform data validation. In fact, it is a nice feature that the schema of the Data is free and up to applications.
However, FIWARE defines Data Models to promote harmonization in certain domains, for instance smart cities. So it is nice to reuse or extend existing data models for the sake of data portability.
Related
Can someone explain to me why you can't connect to a MySQL DB directly through dart from a security point of view?
There is no hard guideline on whether to connect frontend directly to backend or not. It is just a design practice that has been widely accepted and evolved over many years.
Typical app structure consists of
FRONTEND -> SOME MIDDLE LAYER -> BACKEND
Where your middle layer handles all the interactions/processing with the database and the frontend uses this functionality with some sort of API structure. Having this layer is extremely helpful when the application goes to scale, it gives an added abstraction to the frontend.
It is not advisable to directly fuse your frontend(your flutter app), to the DB(MySQL) because any efficient hacker might use basic man-in-middle attack to know your DB structure/connections/queries(There are some pretty effective decompilers present out there), and alter your data and you might not even get to know what caused the data to update unless you've applied some checks on DB layer.
Also, your frontend logic needs to be more of end-user centric than to handle the data of the user. Any backend system(java, node, etc) gives you added functionality & freedom to parse and present the data from either side.
You can use the sqlite package available to store basic data, like your session tokens, your app configurations etc, but it is advisable to keep the main user data like the logins, etc in a separate place, or better yet, you can use the firebase plugin to store data in document structure in the cloud.
The problem I have with the various ORM modules available for databases like MySQL and MongoDB is the inability to keep model information coupled with the database itself.
I want to be able to add a model to my ORM setup at runtime via an administrative HTTP interface and give it some fields that may be ascribed to various predefined data types (like 'email' or 'telephone number'). Possibly the most contentious feature I'm after is the ability to cast a field as a data type that has already been previously defined by the user as a model.
Is this just me trying to have my cake and eat it? Can anybody see a way of implementing something like this? All the ORM modules I've seen so far simply require instantiating models at application level, essentially before runtime.
It's probably worth mentioning I'm hoping to implement this in a Node environment (not a classic LAMP setup).
EDIT:
I take it from the lack of community bite that I may have stumbled back into the Object-Relational Impedance Mismatch issue here?
If your solution depends on multiple drivers, you can try light-orm. It is simple wrapper for relations dbs.
I'm writing a web application using PHP/Symfony2/Doctrine2 and just finishing up the design of the Database. We have to import these objects (for ex. Projects, Vendors) into our database that come from different customers with variety of fields. Some customers have 2 fields in the project object and some have 20. So I was thinking about implementing them in MongoDB since it seems like a good use for it.
Symfony2 supports both ORM and ODM so that shouldn't be a problem, Now my question is how to ensure the integrity of the data in both databases. Because Objects in my MySQL db need to somehow be linked to the objects in the MongoDB for integrity issues.
Are there any better solutions out there? Any help/thoughts would be appreciated
Bulat implemented a Doctrine extension while we were at OpenSky for handling references between MongoDB documents and MySQL records, which is currently sitting in their (admittedly outdated) fork of the DoctrineExtensions project. You'll want to look at either the orm2odm_references or openskyfork branches. For this to be usable in your project, you'll probably want to port it over to a fresh fork of DoctrineExtensions, or simply incorporate the code into your application. Unfortunately, there is no documentation apart from the code itself.
Thankfully, there is also cookbook article on the Doctrine website that describes how to implement this from scratch. Basically, you rely on an event listener to replace your property with a reference (i.e. uninitialized Proxy object) from the other object manager and the natural behavior of Proxy objects to lazily load themselves takes care of the rest. Provided the event listener is a service, you can easily inject both the ORM and ODM object managers into it.
The only integrity guaranteed by this model is that you'll receive exceptions when trying to hydrate a bad reference, which is probably more than you'd get by simply storing an ID of the other database and querying manually.
So the way we solved this problem was by moving to Postgres. Postgres has a datatype called hstore that acts like a NoSQL column. Works pretty sweet
UPDATE
Now that I'm looking back, go with jsonb instead of json or hstore as it allows you to have more of a data structure than a key-value store.
First a background. Our application is built on ASP.NET MVC3, .NET 4.0, and uses Linq-to-Sql (PLINQO) as its primary means of data access. Our web application is a multi-tenant/multi-client system where each client gets their own Sql Server database. Each Sql Server database up to now has had exactly the same schema.
Often times, clients will ask us to track custom fields in their Db that other clients don't track. The way we've handled this is by reserving a number of customfields in the db in our main tables. For example, our Widget table may have a CustomText1, CustomText2.. CustomText10, and a CustomDate1, CustomDate2..CustomDate10 fields. Again, all our schemas across clients are the same, so Linq-to-Sql handles these fields just as easily as any other field.
Now we are running into an issue where a client wants several hundred CustomBool fields, but doesn't need the others. So, basically, we are researching for ways to still use the Linq-to-Sql, but have it work against potentially different schemas depending on the database it is connected to (although they are different in a very specific way.)
Too much code has already been built on Linq-to-Sql and accessing the Widget classes generated by it that I'd like to not just fall back to straight SQL.
I've seen answers here and on the web on ways for Linq to Sql to access different tables that have the same schema, but I have not found a good answer to the same table name across different dbs with different columns.
Is this possible?
If the main objective is to store a few extra fields for existing domain objects then why not create a generic table that can store key value pairs. This is extremely flexible since there is no need to change your schema if a customer requires a new property.
We do this frequently and normally have some helpers to correctly cast the properties e.g.
Service.GetProperty<bool>("SomeCustomProperty")
If you are looking for a more "pluggable" domain model that can be completely different for each tenant, I think you will struggle if you are following a database driven approach and using the L2S designer to generate your code.
To achieve this you really need to be generating your database based on your code (domain driven design) which will give you much more flexibility i.e. you can load a tenant specific configuration (set of classes, business rules etc.) at runtime and use this to generate/validate your schema.
Update
It would be good if you could elaborate on exactly what design approach you have taken i.e. are you using the Linq designer and generating your model from the database?
It's clear that a generic key value pair store is not going to meet your querying requirements.
It's hard to provide a solution without suggesting a different technology. Relational SQL databases aren't really suited for dynamic domain models. You may be better off with a document database such as MongoDb or RavenDb where you are not tied to a specific schema. You could even make use of these just for your custom properties.
If that's not ideal then another solution would be to use something like Dapper to construct your queries. Assuming you are developing against interfaces you can have a implementation of your data service per tenant that makes use of their custom fields.
Ayende did a whole series of posts on Multitenancy and covers tenant specific domain models. It starts here and may be of some use to you.
I'm building an application on top of a legacy database (which I cannot change). I'm using Linq to SQL for the data access, which means I have a (Linq to SQL) class for each table.
My domain model does not match with the database. For example, there are two tables named Users and Employees, and therefore I have two Linq to SQL classes named User and Employee. But in my domain model I'd like to have a User class which should contain some fields from either table (but I don't care about a lot of the other fields of these tables).
I'm not sure how I should design my repositories:
should the repositories perform the mapping between Linq to SQL classes (e.g. User, Employee) to the domain classes (User) and only return the domain classes to the application
or should my repositories return the Linq to SQL classes and leave the mapping to the caller
The first approach seems to make more sense to me, but is this the correct way to implement my repositories?
The purist (I try to stay pure) will tell you that your model represents your data. And therefore, anything that needs to be persisted is done so only when needed through repositories. Also, when you have complex entities, you want to use a service to combine them. For example, User + Employee = UserEmployee entity that is only accessible through an IUserEmployeeService.
With those vague statements, you have an excellent opportunity here.
Build an anti-corruption layer, which allows you to start moving off of the legacy DB at the same time.
This is an another chapter in the DDD playbook. An Anti-Corruption layer is used to interface with a legacy system using Facades, Translators, and Adapters to isolate the legacy DB with your pure Domain model.
Now, this may be a lot more work than you wanted. So, you have to ask yourself at this point:
Do I want to start the process of
moving off of this legacy DB, or will
it remain for the life of the
application?
If your answer is you can start migrating, then model your actual domain the way you want it. Persist it with normal repositories and services. Have fun designing it the way YOU want it stored. Then, use the services of the aggregate roots to reach into the anti-corruption layer and pull out the entities, store/update them locally, and translate into your domain's entities.
If the answer is that the legacy DB will remain for the life of the project, then your task is much easier. Use your domain's services (e.g. UserEmployeeService) to reach into the anti-corruption's UserFacade and EmployeeFacade (similar to a "Remote Service" concept).
Within the Facades, access the legacy db using the Adapters (e.g. LegacyDbSqlDatabase) to get a raw legacyUser(). The next step would be to use an UserTranslator() and EmployeeTranslator() mapper that converts the legacy user data into your actual domain's version of the User() entity, and return it from the UserFacade back to your UserEmployeeService, where it is combined with the Employee entity that came from the same place.
Whoa, that was a lot of typing...
With your Adapters and Facades of your Anti-Corruption layer, you can do your Linq-to-Sql or whatever you want to do. It doesn't matter because you have completely isolated the legacy DB/system away from your nice and pure Domain - your domain that has its own version of User() and Employee() entities and value objects.
DDD and Linq To SQL don't go together very well because the generated classes are not meant to deviate significantly from your DB table structure. You'll have to either map your classes in a way that makes working with Linq to SQL a pain or just live with a non-ideal object model.
If you really want to utilize DDD and the repository pattern go for Entity Framework or even better NHibernate.