Seja bem vindo ao Fórum do JavaFree.org
Aqui você irá encontrar respostas para TUDO o que você precisa sobre java.
Deseja participar? Crie sua conta ou efetue seu login
Só fico preocupado com a licença dele: GPL ou comercial. Não dá pra usar em outros projetos open-source que não sejam GPL também. Esse não é um problema por si só, mas o fato da aplicação que o utiliza precisar dar imports diretos das classes dele, diferentemente de um banco de dados relacional, que a gente importa apenas a API JDBC padrão. Isso faz com que tudo o que o db4o toque vire GPL (ou pago, claro).
_________________ In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
A menos, é claro, que alguém crie um "driver" JDBC para ele, com licença GPL. Acho que poderia funcionar assim: o "driver" faria a persistência de objetos da mesma forma que os DBs Objeto-Relacionais, e as queries seriam feitas através de uma linguagem padrão OQL.
Nesse caso, o "driver" seria GPL, mas o aplicativo que seria conectado a ele não teria essa necessidade, visto que não usa a API nativa. É correta esta forma de pensar? Acho que mesmo que o fornecedor não esteja disposto a mudar a licença, ainda há esperança... _________________ JavaFree.org
A menos, é claro, que alguém crie um "driver" JDBC para ele, com licença GPL. Acho que poderia funcionar assim: o "driver" faria a persistência de objetos da mesma forma que os DBs Objeto-Relacionais, e as queries seriam feitas através de uma linguagem padrão OQL.
Nesse caso, o "driver" seria GPL, mas o aplicativo que seria conectado a ele não teria essa necessidade, visto que não usa a API nativa. É correta esta forma de pensar? Acho que mesmo que o fornecedor não esteja disposto a mudar a licença, ainda há esperança...
Bom, se eles encaixarem o banco de dados OO deles pro padrão JDBC (relacional), isso funcionaria, pois JDBC é um padrão (a aplicação não seria linkada ao driver). Mas isso seria desperdiçar a OO do banco, pois as interfaces JDBC o limitariam (teria que retornar um resultset, não um grafo de objetos, por exemplo). E se eles criassem uma API 'parecida' com JDBC, não ia adiantar também, porque ela seria proprietária. Isso que torna o caso do db4o tão diferente do MySQL, por exemplo, que segue esse esquema de 'driver GPL', mas é só pra assustar, porque o código cliente não depende da API proprietária. Já o db4o sendo GPL, *força* o código a ser GPL. Eu acho =)
_________________ In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Bem, não seriam "eles", a própria comunidade poderia dar suporte ao "driver" JDBC.
Mediante um truque bem cara-de-pau, a OO do banco não seria desperdiçada, pois um getObject() no ResultSet recuperaria uma referência ao objeto procurado (uma coleção ou objeto raiz). Funciona pq o "banco de dados" estaria funcionando em via de regra na mesma JVM da aplicação, tornando válida a referência retornada. _________________ JavaFree.org
Bem, não seriam "eles", a própria comunidade poderia dar suporte ao "driver" JDBC.
Mediante um truque bem cara-de-pau, a OO do banco não seria desperdiçada, pois um getObject() no ResultSet recuperaria uma referência ao objeto procurado (uma coleção ou objeto raiz). Funciona pq o "banco de dados" estaria funcionando em via de regra na mesma JVM da aplicação, tornando válida a referência retornada.
Nossa, gambiarra total... but clever! Não posso negar que é uma boa idéia! Eu acho que ainda perderíamos muitas facilidades do banco, mas nos livraríamos da obrigação de comprar o db4o (rsrsrs), se mantivéssemos o acesso apenas pelo driver JDBC... (sem NENHUM import!) =)
_________________ In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Depois que alguém faz um buraco na porteira, alguém abre a fechadura... Se alguém fizer isso, seria um bom argumento para liberarem tudo em licença MIT ou LGPL... _________________ JavaFree.org
Alguém sabe se o db4o mantém os objetos em memória, que nem o Prevayler? (argh!)
_________________ In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Mas se cada vez que vou persistir ou recuperar devo fazer "gambi" com uma pseudo-ponte-jdbc (essa foi feia ops: ), neste caso, qual a facilidade em utilizá-lo ?
Mas se cada vez que vou persistir ou recuperar devo fazer "gambi" com uma pseudo-ponte-jdbc (essa foi feia ops: ), neste caso, qual a facilidade em utilizá-lo ?
EXATAMENTE! hehe (eu não gosto muito de ODBMSs)
_________________ In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
A coisa mais ideal seria uma especificação comum (como JDBC) para ODBMs, que os fabricantes pudessem implementar. Aí não haveria gambiarra...
O problema que temos hoje é que cada ODBMs implementa sua própria API de acesso. É o mesmo problema que já tivemos com bases relacionais no passado.
_________________ JavaFree.org
Olá caro copernico(nome que encontramos no fórum).. estamos estudando ferramentas de BD na qual estamos tentando instalar o db4o. Baixamos a versão da página do fabricante, mas não entendemos como colocala pra rodar. Gostariamos que se possível pudesse nos auxiliar nesta tarefa, pois é de grande importância para nós...
daltoncamargo Offline
Posts: 8768
Esta página exibe apenas os comentários deste tutorial, para ler o artigo, clique aqui.
jef Offline
Posts: 46
Legal Aspirante, espero que no futuro possamos usar somente este tipo de banco de dados.
O tutorial esta muito massa.
ronaldtm Offline
Posts: 2299
Só fico preocupado com a licença dele: GPL ou comercial. Não dá pra usar em outros projetos open-source que não sejam GPL também. Esse não é um problema por si só, mas o fato da aplicação que o utiliza precisar dar imports diretos das classes dele, diferentemente de um banco de dados relacional, que a gente importa apenas a API JDBC padrão. Isso faz com que tudo o que o db4o toque vire GPL (ou pago, claro).
_________________
In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Copernico Offline
Posts: 530
Realmente o ideal seria uma licença LGPL...
A menos, é claro, que alguém crie um "driver" JDBC para ele, com licença GPL. Acho que poderia funcionar assim: o "driver" faria a persistência de objetos da mesma forma que os DBs Objeto-Relacionais, e as queries seriam feitas através de uma linguagem padrão OQL.
Nesse caso, o "driver" seria GPL, mas o aplicativo que seria conectado a ele não teria essa necessidade, visto que não usa a API nativa. É correta esta forma de pensar? Acho que mesmo que o fornecedor não esteja disposto a mudar a licença, ainda há esperança...
_________________
JavaFree.org
daltoncamargo Offline
Posts: 8768
Amigo, o tutorial não é meu, é do :
Andrews Medina (cybermix)
Méritos indiscutíveis a ele
_________________
Dalton Camargo
Sugestão de Livro do JavaFree para os iniciantes em Java
ronaldtm Offline
Posts: 2299
Bom, se eles encaixarem o banco de dados OO deles pro padrão JDBC (relacional), isso funcionaria, pois JDBC é um padrão (a aplicação não seria linkada ao driver). Mas isso seria desperdiçar a OO do banco, pois as interfaces JDBC o limitariam (teria que retornar um resultset, não um grafo de objetos, por exemplo). E se eles criassem uma API 'parecida' com JDBC, não ia adiantar também, porque ela seria proprietária. Isso que torna o caso do db4o tão diferente do MySQL, por exemplo, que segue esse esquema de 'driver GPL', mas é só pra assustar, porque o código cliente não depende da API proprietária. Já o db4o sendo GPL, *força* o código a ser GPL. Eu acho =)
_________________
In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Copernico Offline
Posts: 530
Bem, não seriam "eles", a própria comunidade poderia dar suporte ao "driver" JDBC.
Mediante um truque bem cara-de-pau, a OO do banco não seria desperdiçada, pois um getObject() no ResultSet recuperaria uma referência ao objeto procurado (uma coleção ou objeto raiz). Funciona pq o "banco de dados" estaria funcionando em via de regra na mesma JVM da aplicação, tornando válida a referência retornada.
_________________
JavaFree.org
ronaldtm Offline
Posts: 2299
Nossa, gambiarra total... but clever! Não posso negar que é uma boa idéia! Eu acho que ainda perderíamos muitas facilidades do banco, mas nos livraríamos da obrigação de comprar o db4o (rsrsrs), se mantivéssemos o acesso apenas pelo driver JDBC... (sem NENHUM import!) =)
_________________
In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Copernico Offline
Posts: 530
Depois que alguém faz um buraco na porteira, alguém abre a fechadura... Se alguém fizer isso, seria um bom argumento para liberarem tudo em licença MIT ou LGPL...
_________________
JavaFree.org
ronaldtm Offline
Posts: 2299
Alguém sabe se o db4o mantém os objetos em memória, que nem o Prevayler? (argh!)
_________________
In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
mhudson Offline
Posts: 9
Mas se cada vez que vou persistir ou recuperar devo fazer "gambi" com uma pseudo-ponte-jdbc (essa foi feia
ronaldtm Offline
Posts: 2299
EXATAMENTE! hehe (eu não gosto muito de ODBMSs)
_________________
In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Copernico Offline
Posts: 530
A coisa mais ideal seria uma especificação comum (como JDBC) para ODBMs, que os fabricantes pudessem implementar. Aí não haveria gambiarra...
O problema que temos hoje é que cada ODBMs implementa sua própria API de acesso. É o mesmo problema que já tivemos com bases relacionais no passado.
_________________
JavaFree.org
cpcristian Offline
Posts: 0
Olá caro copernico(nome que encontramos no fórum).. estamos estudando
ferramentas de BD na qual estamos tentando instalar o db4o. Baixamos a
versão da página do fabricante, mas não entendemos como colocala pra rodar.
Gostariamos que se possível pudesse nos auxiliar nesta tarefa, pois é de
grande importância para nós...
Desde ja Agradecemos
maze Offline
Posts: 84
Mandem a ideia pro JCP
_________________
Felipe Fernandes
http://www.badgerbadgerbadger.com
Você ainda risca seu caderno ?
http://freemind.sourceforge.net/
agnm Offline
Posts: 6
qual é a versão mais atual desse db4o ?
_________________
JavaFree.org
vfpamp Offline
Posts: 6009
5.0
[]s
_________________
Vitor Pamplona
http://vitorpamplona.com
http://twitter.com/vitorpamplona
Não respondo dúvidas por e-mail, nem msn, nem via private message. Use o fórum para isso.
esstein Offline
Posts: 8
Alguém já testou a 6.4?
_________________
[]'s
Evandro
Relacionados
RMI http://javafree.uol.com.br/topic-2388-RMI.html Introdução: Inversion of Control http://javafree.uol.com.br/topic-8216-Introducao-Inversion-of-Control.html Chat na Web(WebChat) http://javafree.uol.com.br/topic-6078-Chat-na-WebWebChat.html Conceitos http://javafree.uol.com.br/topic-856206-Conceitos.html J2ME ou SuperWaba com DB4objects http://javafree.uol.com.br/topic-863126-J2ME-ou-SuperWaba-com-DB4objects.html Não estou conseguindo usar o JCreator http://javafree.uol.com.br/topic-848102-Nao-estou-conseguindo-usar-o-JCreator.html O fabuloso gerador de Lero-Lero ! http://javafree.uol.com.br/topic-852698-O-fabuloso-gerador-de-LeroLero.html Qual Library para criar em 2D ? http://javafree.uol.com.br/topic-5784-Qual-Library-para-criar-em-2D.html J2EE http://javafree.uol.com.br/topic-10531-J2EE.html