Je recherche de l'information concernant , le passage de flux de
donn=E9e du serveur au client.
Nous avons un serveur qui execute des r=E9qu=EAtes. Nous voudrions
trouver un moyen de retourner le ResultSet vers le Client.
Notez que le serveur fait office de proxy par rapport au client et au
SGBD. Nous d=E9sirons afficher le r=E9sultat de ces commandes SQL dans un
JTable (Cot=E9 Client).
Apr=E8s plusieurs recherches, la seule solution que nous avions
envisag=E9 est la transformation du ResultSet sous forme d'une chaine de
caract=E8re qui n'est pas n=E9cessairement tr=E8s facile =E0 manipuler en
plus de ne pas =EAtre optimale.
L'utilisation d'un AbstractTableModel est-elle envisageable ? =C9tant
donn=E9 que nous pourrions la serializ=E9. Elle passerait vers un
ObjectOutputStream.
Notez que cette application est multiThread afin de permettre la
connection multiple au serveur.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
alexandre cartapanis
Bonjour à tous,
Je recherche de l'information concernant , le passage de flux de donnée du serveur au client.
Nous avons un serveur qui execute des réquêtes. Nous voudrions trouver un moyen de retourner le ResultSet vers le Client. Notez que le serveur fait office de proxy par rapport au client et au SGBD. Nous désirons afficher le résultat de ces commandes SQL dans un JTable (Coté Client).
Après plusieurs recherches, la seule solution que nous avions envisagé est la transformation du ResultSet sous forme d'une chaine d e caractère qui n'est pas nécessairement très facile à manipuler en plus de ne pas être optimale.
L'utilisation d'un AbstractTableModel est-elle envisageable ? Étant donné que nous pourrions la serializé. Elle passerait vers un ObjectOutputStream.
Notez que cette application est multiThread afin de permettre la connection multiple au serveur.
Avez-vous des suggestions?
Merci et salutations.
Pour faire ça, moi j'ai implémenté mes propres classes, qui prennen t un
resultset en paramètre (du constructeur) et qui sont serializable. Le souci c'est que tu perds le coté "dynamique" premièrement, et ensuite a chaque fois, le resultset est "copié" dans un objet, donc occupation mémoire importante. L'avantage, c'est que ces objets, une fois créé , sont utilisable via RMI par exemple, ou toute autres formes de serialization.
Si tu veux en savoir plus fais le moi savoir, je peux éventuellement te fournir les classes utilisées.
-- Alexandre CARTAPANIS - Responsable Système et Réseau Email Gsm. 06 72 07 51 55
Je recherche de l'information concernant , le passage de flux de
donnée du serveur au client.
Nous avons un serveur qui execute des réquêtes. Nous voudrions
trouver un moyen de retourner le ResultSet vers le Client.
Notez que le serveur fait office de proxy par rapport au client et au
SGBD. Nous désirons afficher le résultat de ces commandes SQL dans un
JTable (Coté Client).
Après plusieurs recherches, la seule solution que nous avions
envisagé est la transformation du ResultSet sous forme d'une chaine d e
caractère qui n'est pas nécessairement très facile à manipuler en
plus de ne pas être optimale.
L'utilisation d'un AbstractTableModel est-elle envisageable ? Étant
donné que nous pourrions la serializé. Elle passerait vers un
ObjectOutputStream.
Notez que cette application est multiThread afin de permettre la
connection multiple au serveur.
Avez-vous des suggestions?
Merci et salutations.
Pour faire ça, moi j'ai implémenté mes propres classes, qui prennen t un
resultset en paramètre (du constructeur) et qui sont serializable. Le
souci c'est que tu perds le coté "dynamique" premièrement, et ensuite a
chaque fois, le resultset est "copié" dans un objet, donc occupation
mémoire importante. L'avantage, c'est que ces objets, une fois créé ,
sont utilisable via RMI par exemple, ou toute autres formes de
serialization.
Si tu veux en savoir plus fais le moi savoir, je peux éventuellement te
fournir les classes utilisées.
--
Alexandre CARTAPANIS - Responsable Système et Réseau
Email alexandre.cartapanis@macymed.fr
Gsm. 06 72 07 51 55
Je recherche de l'information concernant , le passage de flux de donnée du serveur au client.
Nous avons un serveur qui execute des réquêtes. Nous voudrions trouver un moyen de retourner le ResultSet vers le Client. Notez que le serveur fait office de proxy par rapport au client et au SGBD. Nous désirons afficher le résultat de ces commandes SQL dans un JTable (Coté Client).
Après plusieurs recherches, la seule solution que nous avions envisagé est la transformation du ResultSet sous forme d'une chaine d e caractère qui n'est pas nécessairement très facile à manipuler en plus de ne pas être optimale.
L'utilisation d'un AbstractTableModel est-elle envisageable ? Étant donné que nous pourrions la serializé. Elle passerait vers un ObjectOutputStream.
Notez que cette application est multiThread afin de permettre la connection multiple au serveur.
Avez-vous des suggestions?
Merci et salutations.
Pour faire ça, moi j'ai implémenté mes propres classes, qui prennen t un
resultset en paramètre (du constructeur) et qui sont serializable. Le souci c'est que tu perds le coté "dynamique" premièrement, et ensuite a chaque fois, le resultset est "copié" dans un objet, donc occupation mémoire importante. L'avantage, c'est que ces objets, une fois créé , sont utilisable via RMI par exemple, ou toute autres formes de serialization.
Si tu veux en savoir plus fais le moi savoir, je peux éventuellement te fournir les classes utilisées.
-- Alexandre CARTAPANIS - Responsable Système et Réseau Email Gsm. 06 72 07 51 55
Cela peut s'avérer fort utile en effet, l'occupation de la mémoire est de quelle importance exactement? assez grande j,imagine.... l'analyse de chaîne ne m'enchante pas beaucoup car relativement fastidieuse et je ne parle pas du côté performences...
Je serais, oui intéressé à voir tes classes pour une utilisation future :)
Merci de ta réponse mon cher
Cela peut s'avérer fort utile en effet, l'occupation de la mémoire
est de quelle importance exactement? assez grande j,imagine....
l'analyse de chaîne ne m'enchante pas beaucoup car relativement
fastidieuse et je ne parle pas du côté performences...
Je serais, oui intéressé à voir tes classes pour une utilisation
future :)
Cela peut s'avérer fort utile en effet, l'occupation de la mémoire est de quelle importance exactement? assez grande j,imagine.... l'analyse de chaîne ne m'enchante pas beaucoup car relativement fastidieuse et je ne parle pas du côté performences...
Je serais, oui intéressé à voir tes classes pour une utilisation future :)
Merci de ta réponse mon cher
ekse
Bonjour à tous,
Je recherche de l'information concernant , le passage de flux de donnée du serveur au client.
Nous avons un serveur qui execute des réquêtes. Nous voudrions trouver un moyen de retourner le ResultSet vers le Client. Notez que le serveur fait office de proxy par rapport au client et au SGBD. Nous désirons afficher le résultat de ces commandes SQL dans un JTable (Coté Client).
Après plusieurs recherches, la seule solution que nous avions envisagé est la transformation du ResultSet sous forme d'une chaine de caractère qui n'est pas nécessairement très facile à manipuler en plus de ne pas être optimale.
L'utilisation d'un AbstractTableModel est-elle envisageable ? Étant donné que nous pourrions la serializé. Elle passerait vers un ObjectOutputStream.
Notez que cette application est multiThread afin de permettre la connection multiple au serveur.
Avez-vous des suggestions?
Merci et salutations.
Salut,
Tu devrais regarder du côté d'Hibernate par exemple qui te permet assez simplement de mapper tes tables SQL dans des classes java.
Via un fichier XML ou via les annotations, tu dis quelle colonne de ta table est associée à quelle variable de ta classe.
Tu gagnes en plus en indépendance par rapport à la base de données utilisée n'en faisant mention que dans un fichier de configuration.
www.hibernate.org
N'hésites pas à me demander plus d'info.
Bonjour à tous,
Je recherche de l'information concernant , le passage de flux de
donnée du serveur au client.
Nous avons un serveur qui execute des réquêtes. Nous voudrions
trouver un moyen de retourner le ResultSet vers le Client.
Notez que le serveur fait office de proxy par rapport au client et au
SGBD. Nous désirons afficher le résultat de ces commandes SQL dans un
JTable (Coté Client).
Après plusieurs recherches, la seule solution que nous avions
envisagé est la transformation du ResultSet sous forme d'une chaine de
caractère qui n'est pas nécessairement très facile à manipuler en
plus de ne pas être optimale.
L'utilisation d'un AbstractTableModel est-elle envisageable ? Étant
donné que nous pourrions la serializé. Elle passerait vers un
ObjectOutputStream.
Notez que cette application est multiThread afin de permettre la
connection multiple au serveur.
Avez-vous des suggestions?
Merci et salutations.
Salut,
Tu devrais regarder du côté d'Hibernate par exemple qui te permet
assez simplement de mapper tes tables SQL dans des classes java.
Via un fichier XML ou via les annotations, tu dis quelle colonne de ta
table est associée à quelle variable de ta classe.
Tu gagnes en plus en indépendance par rapport à la base de données
utilisée n'en faisant mention que dans un fichier de configuration.
Je recherche de l'information concernant , le passage de flux de donnée du serveur au client.
Nous avons un serveur qui execute des réquêtes. Nous voudrions trouver un moyen de retourner le ResultSet vers le Client. Notez que le serveur fait office de proxy par rapport au client et au SGBD. Nous désirons afficher le résultat de ces commandes SQL dans un JTable (Coté Client).
Après plusieurs recherches, la seule solution que nous avions envisagé est la transformation du ResultSet sous forme d'une chaine de caractère qui n'est pas nécessairement très facile à manipuler en plus de ne pas être optimale.
L'utilisation d'un AbstractTableModel est-elle envisageable ? Étant donné que nous pourrions la serializé. Elle passerait vers un ObjectOutputStream.
Notez que cette application est multiThread afin de permettre la connection multiple au serveur.
Avez-vous des suggestions?
Merci et salutations.
Salut,
Tu devrais regarder du côté d'Hibernate par exemple qui te permet assez simplement de mapper tes tables SQL dans des classes java.
Via un fichier XML ou via les annotations, tu dis quelle colonne de ta table est associée à quelle variable de ta classe.
Tu gagnes en plus en indépendance par rapport à la base de données utilisée n'en faisant mention que dans un fichier de configuration.
www.hibernate.org
N'hésites pas à me demander plus d'info.
Laurent M
j'y avais songé mais ce que je dois faire est un devoir et les spécifications ne parlent pas d'utiliser Hibernate.
Merci quand même
j'y avais songé mais ce que je dois faire est un devoir et les
spécifications ne parlent pas d'utiliser Hibernate.
j'y avais songé mais ce que je dois faire est un devoir et les spécifications ne parlent pas d'utiliser Hibernate.
Merci quand même
jnizet
Le serveur doit offrir l'interface la plus propre et la plus claire possible au client. Il doit l'isoler des détails d'implémentation (nom des tables, des colonnes, etc.) Il doit également être indépendant du client: retourner un AbstractTableModel est une mauvaise idée, parce que ça lie le code du serveur à la technologie (Swing) utilisée par le client. Si tu as plusieurs clients, ou que le client devient une webapp, l'AbstractTableModel devient plus difficilement utilisable. De plus, tu ne peux pas préjuger de la manière dont les données vont être affichées. Par exemple: si la donnée est un booléen, tu dois retourner un booléen, et pas une chaîne "oui" ou "non". C'est pareil pour les dates. Pense aussi qu'une bonne application doit pouvoir être internationalisée. Les données doivent donc être retournées sans présupposition de la langue utilisée par le client.
Donc, pour répondre à ta question, retourne des objets, contenant tes données retournées de manière structurée (exemple: une collection de User ayant chacun une instance d'Address). Pense aussi qu'il te faudra souvent plusieurs requêtes, et donc plusieurs ResultSets pour obtenir les données que le client désire afficher. D'ordinaire, on se base sur RMI pour ce genre de problème, et on retourne des objets respectant les conventions des JavaBeans (getters, Serializable). C'est beaucoup plus simple que d'implémenter sa propre gestion des threads, connexions, etc.
JB.
Le serveur doit offrir l'interface la plus propre et la plus claire
possible au client. Il doit l'isoler des détails d'implémentation
(nom des tables, des colonnes, etc.)
Il doit également être indépendant du client: retourner un
AbstractTableModel est une mauvaise idée, parce que ça lie le code du
serveur à la technologie (Swing) utilisée par le client. Si tu as
plusieurs clients, ou que le client devient une webapp,
l'AbstractTableModel devient plus difficilement utilisable. De plus, tu
ne peux pas préjuger de la manière dont les données vont être
affichées.
Par exemple: si la donnée est un booléen, tu dois retourner un
booléen, et pas une chaîne "oui" ou "non". C'est pareil pour les
dates. Pense aussi qu'une bonne application doit pouvoir être
internationalisée. Les données doivent donc être retournées sans
présupposition de la langue utilisée par le client.
Donc, pour répondre à ta question, retourne des objets, contenant tes
données retournées de manière structurée (exemple: une collection
de User ayant chacun une instance d'Address). Pense aussi qu'il te
faudra souvent plusieurs requêtes, et donc plusieurs ResultSets pour
obtenir les données que le client désire afficher.
D'ordinaire, on se base sur RMI pour ce genre de problème, et on
retourne des objets respectant les conventions des JavaBeans (getters,
Serializable). C'est beaucoup plus simple que d'implémenter sa propre
gestion des threads, connexions, etc.
Le serveur doit offrir l'interface la plus propre et la plus claire possible au client. Il doit l'isoler des détails d'implémentation (nom des tables, des colonnes, etc.) Il doit également être indépendant du client: retourner un AbstractTableModel est une mauvaise idée, parce que ça lie le code du serveur à la technologie (Swing) utilisée par le client. Si tu as plusieurs clients, ou que le client devient une webapp, l'AbstractTableModel devient plus difficilement utilisable. De plus, tu ne peux pas préjuger de la manière dont les données vont être affichées. Par exemple: si la donnée est un booléen, tu dois retourner un booléen, et pas une chaîne "oui" ou "non". C'est pareil pour les dates. Pense aussi qu'une bonne application doit pouvoir être internationalisée. Les données doivent donc être retournées sans présupposition de la langue utilisée par le client.
Donc, pour répondre à ta question, retourne des objets, contenant tes données retournées de manière structurée (exemple: une collection de User ayant chacun une instance d'Address). Pense aussi qu'il te faudra souvent plusieurs requêtes, et donc plusieurs ResultSets pour obtenir les données que le client désire afficher. D'ordinaire, on se base sur RMI pour ce genre de problème, et on retourne des objets respectant les conventions des JavaBeans (getters, Serializable). C'est beaucoup plus simple que d'implémenter sa propre gestion des threads, connexions, etc.
JB.
alexandre cartapanis
Cela peut s'avérer fort utile en effet, l'occupation de la mémoire est de quelle importance exactement? assez grande j,imagine....
C'est pas énorme non plus. A vrai dire je n'ai jamais mesuré précisément, mais en gros ça prends "2 result set".
Enfin ce n'est clairement pas une solution adaptée à une montée en charge importante...
l'analyse de chaîne ne m'enchante pas beaucoup car relativement fastidieuse et je ne parle pas du côté performences...
Je serais, oui intéressé à voir tes classes pour une utilisation future :)
Ben dis moi ou je peux te les envoyer...
Merci de ta réponse mon cher
-- Alexandre CARTAPANIS - Responsable Système et Réseau Email Gsm. 06 72 07 51 55
Tu peux aussi jeter un oeil aux Jakarta Common BeanUtils : tu y trouveras notamment des classes qui te permettront de mapper automatiquement des collections de beans sur des resultset et de créer automatiquement des beans à l'image de tes "rows". Tu manipules alors tes enregistrements avec la souplesse des getter/setter... sans jamais avoir à te soucier de définir "a priori" les classes beans correspondantes !
Exemple de code :
ResultSet rs = ...; ResultSetDynaClass rsdc = new ResultSetDynaClass(rs); Iterator rows = rsdc.iterator(); while (rows.hasNext()) { DynaBean row = (DynaBean) rows.next(); ... process this row ... ... lvalue = row.get("MA_COLONNE); } rs.close();
Pour en savoir plus : http://jakarta.apache.org/commons/beanutils/
-- David
Tu peux aussi jeter un oeil aux Jakarta Common BeanUtils : tu y
trouveras notamment des classes qui te permettront de mapper
automatiquement des collections de beans sur des resultset et de créer
automatiquement des beans à l'image de tes "rows". Tu manipules alors
tes enregistrements avec la souplesse des getter/setter... sans jamais
avoir à te soucier de définir "a priori" les classes beans
correspondantes !
Exemple de code :
ResultSet rs = ...;
ResultSetDynaClass rsdc = new ResultSetDynaClass(rs);
Iterator rows = rsdc.iterator();
while (rows.hasNext()) {
DynaBean row = (DynaBean) rows.next();
... process this row ...
... lvalue = row.get("MA_COLONNE);
}
rs.close();
Pour en savoir plus : http://jakarta.apache.org/commons/beanutils/
Tu peux aussi jeter un oeil aux Jakarta Common BeanUtils : tu y trouveras notamment des classes qui te permettront de mapper automatiquement des collections de beans sur des resultset et de créer automatiquement des beans à l'image de tes "rows". Tu manipules alors tes enregistrements avec la souplesse des getter/setter... sans jamais avoir à te soucier de définir "a priori" les classes beans correspondantes !
Exemple de code :
ResultSet rs = ...; ResultSetDynaClass rsdc = new ResultSetDynaClass(rs); Iterator rows = rsdc.iterator(); while (rows.hasNext()) { DynaBean row = (DynaBean) rows.next(); ... process this row ... ... lvalue = row.get("MA_COLONNE); } rs.close();
Pour en savoir plus : http://jakarta.apache.org/commons/beanutils/
-- David
Laurent M
J'ai trouvé la solution : http://www.rgagnon.com/javadetails/java-0511.html
-- Reste à savoir si je peux reconstruire le fichier xml à partir du flux renvoyé au client
J'ai trouvé la solution :
http://www.rgagnon.com/javadetails/java-0511.html
--
Reste à savoir si je peux reconstruire le fichier xml à partir du
flux renvoyé au client
