I have been thinking about using JDO in my new project. However, there is always the possibility of changing the Programming language, or rewriting / adding some modules in other languages. But i fear that in that case the data may not be accessible (parseable, understandable).
Are my fears justified?
If you persist data using JDO to say RDBMS, then the data is held in RDBMS (in a logical well-defined structure) which is equally accessible using SQL via a different programming language. The datastore is what holds the data, not some mysterious "JDO" thing, which is simply an API to get the data there from a Java app and Java objects.
Related
I want to implement some game logic with a lot of relations between objects similar to those of relational databases or graph databases.
I know no language that would both allow me to do :
Strong, safe relationnal mapping with non nullable links, cascade deletion, ect.
Implement game logic
Write pure functions
Networking
If possible, a decent data access performance. (Like in-memory SQLlite is acceptable)
I want to avoid using 2 languages and map the data between both using some quite complex ORM. Instead I would like a language that is capable of all of these.
Obsiouly, there is SQL. But I do not know any implementation of SQL that :
Is capable of networking other than replying to SQL requests
Have the many features of a language like F# ? SQL is capable of functional programming but what about F# features like pipes, partial applications, pattern matching, strong typing over primitive types ?
I will accept partial alternative solutions.
Note that I do not need actual persistance storage, only objects relation like relationnal databases, or even graph databases do.
The answer is no, within the bounds as you have set them.
The purpose of The Third Manifesto is to define a language called D, which has the features of a general purpose programming language but implements a type system and relational features specifically aimed at database management. If implemented fully it might replace SQL, but not common GP languages such as C/C++, Java or C#.
There are many GP languages which can do all the things you propose, when used in conjunction with suitably chosen libraries. For the closest match to what you describe, you should stick with any language that suits your other needs, and add to it an in-memory in-process database that uses an API and not SQL. Almost by definition that means you should look for a 'NoSQL' database. There are many.
You question was mentioned here: https://forum.thethirdmanifesto.com/forum/topic/is-there-a-language-that-does-both-what-sql-does-and-general-purpose-programming/. You might find subsequent discussion enlightening.
I am building a system in Scala for feature engineering where the end user API receives aggregations on list of objects/events.
For example, a client of this tool might pass into it a function that given an array of past pageviews for a specific web user, filters for the ones coming from a specify country and count them. The output of this call will then be a number.
It can be thought as a very simple reduce operation.
I am figuring out how to build the API for such system. I could write a simple custom language to perform counts and filters but I am sure that it is not the best approach, especially because it will not be expressive enough, unless designed with care.
Are you aware of something like an expression language that could be used to express simple functions without the need for me to build one from scratch?
The other option would be to allow end users to pass custom code to this library, which might be dangerous at runtime.
I am aware of apache Calcite to plug SQL into different data structures and db. It is a good option, however it forces me to think in "columnar" sql way, while here I am looking more for something row based, similar to the map-reduce way of programming.
You mention Apache Calcite, but did you know that you can use it without writing SQL? If you use Calcite's RelBuilder class you can build algebra directly, which is very similar to the algebraic approach of MapReduce. See algebra in Calcite for more details.
I am fairly new to using packages. My team is deciding on whether or not to use packages in our applications. We have 4 applications that are using in-line sql currently. We are deciding on putting each sql statement in a stored procedure and then logically grouping the Stored procedure into packages(These stored procedures will be shared among the applications). What are the potential pros and cons of using packages.
Our applications are written in asp.net using c#.
So you want to start a debate about the advantages versus the disadvantages of using a package? Ok, then I would leave the disadvantages part on you if you could share with us. I will just share with you tye advantages, not in my own words, since it would be a repetition of what Thomas Kyte already said here:
break the dependency chain (no cascading invalidations when you install a new package body -- if
you have procedures that call procedures -- compiling one will invalidate your database)
support encapsulation -- I will be allowed to write MODULAR, easy to understand code -- rather
then MONOLITHIC, non-understandable procedures
increase my namespace measurably. package names have to be unique in a schema, but I can have
many procedures across packages with the same name without colliding
support overloading
support session variables when you need them
promote overall good coding techniques, stuff that lets you write code that is modular,
understandable, logically grouped together....
If you are a programmer - you would see the benefits of packages over a proliferation of standalone
procedures in a heartbeat.
If you're going to have different applications accessing the same tables, with the same business logic happening on the database (eg. constraints, etc), then stored procs are the way to go. Think of them as the interface between the "front end" (ie. anything that's not the database) and the database, in much the same way as a webservice provides an interface to the mid-tier (I think; I'm really not up on the non-db related architecture!).
Your publically callable stored procedures would be typically things like create_a_new_customer, add_a_new_address, retrieve_customer_details, etc, where the logic behind each action is coded and related procedures would be grouped into the same package. You wouldn't want to code a series of procedures that just do dml on the tables and expect the applications to work out when to call each procedure.
Here's a handy decision diagram for this question.
Just adding a side effect of using packages...
If I have a package with all the stored procedures and functions that is required for my application to run. Consider one small stored procedure suddenly fail due to some issue(eg. some alteration in table structure) or some other minor issue so that only one stored procedure becomes invalid.
In this case, will the entire package become invalid? Affecting the entire application?
On the other hand if do not use package and create standalone procs and functions, then only one proc will fail.
I started Meteor a few months ago.
I would like to know if using cursor.observeChanges for buisness objects is a good idea
I want to separate operations and views so I can uses the same operations in many views/events, and I want to know if it is a good idea.
Someone told me, we should not separate operations on mongo from view.
So my question is : Is it a good idea to to Buisness Objects with Meteor ?
Tanks for reading me.
cursor.observeChanges is essentially what you get behind the scenes when you do normal find() queries and bind to template helpers due to its context being reactive.
In the meteor world, the traditional model/view/controller paradigm is shifted towards a reactive data-on-the-wire concept including features like latency compensation.
What you refer to as a business object is basically a representation of your business data which is strongly typed, has a type of its own, atomic, and has only one task of representing.
You can achieve that kind of separation of concerns in any language/framework, including meteor. That only depends on how you lay out, structure and abstract your code.
What Meteor brings into the equation is the toolset to build up an interface to your data with modern ux features that are otherwise very hard/expensive to get.
The only concern over business-class applications could be the fact that Meteor currently employs MongoDB by default. MongoDB has its own discussions around business applications whether they need transaction support, ad-hoc aggregation, foreign key relationships etc. But that is another topic.
I'm coming from a Ruby on Rails environment and I'm really spoiled with Active Record there. I did a small proof of concept project using sqlite on the iPhone and I realize even more how much I'm spoiled ;)
For the next application I consider using Core Data (as I believe the way it works will be close to Active Record). My App will provide the user with a lot of data to use (with many related tables) and I intend to update that data on a regular base (each 2-3 months). With sqlite this would be as simple as downloading an sqlite file, is it also that simple using Core Data ?
Core Data is very similar to Active Data Record. The primary difference is that Active Data evolved from SQL store into the application objects code whereas Core Data evolved from the application objects towards a variety of stores. More concisely, Active Data does not work without a SQL store but Core Data works fine with no store of any kind.
As such, Core Data real strength lays in modeling complex relationships between objects. The type of persistent store used (if any) is largely irrelevant. Core Data makes it very easy to link complex models to complex computer and human interfaces.
The flip side is that you have to maintain the integrity of the object graph so you can't batch import the persistent store. You download the data, create managed objects and insert them into persistent store. While this seems complex and slow, it is really not especially compared to downloading an entire store whether you need all the data in it or not.
Even if it is more complex, the ease of integrating Core Data into the rest of the app usually pays off.
If you are thinking about writing and maintaining several iOS apps then it would be worth your time to climb Core Data's learning curve.
SQLite is a persistent store, Core Data is an object graph. They're not exactly the same thing -- though Core Data can live on top of SQLite.
Really it depends on how much data you're going to be storing, and how often you need to look it up in addition to write it. Your update process is going to be a lot more difficult using Core Data than SQLite, especially if you have a lot of data; however, it may be easier to work with for the common case (small updates, reads), which could offset many of these issues.